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Moving existing legacy systems to cloud platforms is an ever popular option. But, such endeavour may 
not be hazard-free and demands a proper understanding of requirements and risks involved prior to tak¬ 
ing any action. The time is indeed ripe to undertake a realistic view of what migrating legacy systems to 
cloud may offer, an understanding of exceptional situations causing system quality goal failure in such a 
transition, and insights on countermeasures. The cloud migration body of knowledge, although is useful, 
is dispersed over the current literature. It is hard for busy practitioners to digest, synthesize, and harness 
this body of knowledge into practice when integrating legacy systems with cloud services. We address 
this issue by creating an innovative synergy between the approaches evidence-based software engineer¬ 
ing and goal-oriented modelling. We develop an evidential repository of commonly occurred obstacles 
and platform agnostic resolution tactics related to cloud enablement of legacy systems. The repository 
is further utilized during systematic goal-obstacle elaboration of given cloud migration scenarios. The 
applicability of our proposed framework is also demonstrated. 

© 2017 Elsevier Inc. All rights reserved. 


1. Introduction 

Cloud computing is a fundamental shift in delivering IT services 
to software systems. A perennial concern of IT managers embark¬ 
ing on migrating critical legacy systems to cloud platforms is to 
ensure attainability of the services in their organisational setting 
(Zardari et al„ 2014; Khajeh-Hosseini et al., 2011). Despite perva¬ 
siveness and hype over cloud computing, some organisations are 
still reluctant to undertake migration project. Whether the mi¬ 
gration is of legacy systems to the cloud or changing an existing 
cloud platform, perceived uncertainties often hinder undertaking 
such projects. Uncertainties originate from various factors, e.g. se¬ 
curity, failure experience of other organisations, vendor lock-in in 
the absence of standards, cultural shift, uncertain jurisdiction for 
activities over distributed cloud data centres, service outage, and 
many others (Chow et al„ 2009; Pepitone, 2011; Linthicum, 2012; 
Tsidulko, 2016). For example, cloud services reliability are some¬ 
times questioned because of the outage of Google GMail service or 
Microsoft’s Danger division’s causing loss of some of the data of 
customers. Failure to adequately identify and mitigate such risks 
beforehand may become costly to rectify if they are detected in 
later stages when legacy systems are already in operating in the 
cloud. Ideally, such issues should be accounted for requirement 
analysis time when system goals are being identified. This would 
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allow more flexibility to negotiate multiple trade-off and it can 
lead to a cheaper overall outcome in a satisfactory way. 

Since the emergence of cloud computing technology in 2007, 
there has been an ever increasing number of versatile accounts, 
published by both academia and industrial communities, on ef¬ 
fective adoption of cloud services to augment the operation and 
maintenance of legacy systems in different organisational and 
project settings. Such documented accounts provide a test bed that 
can be reused for informed decision making in moving legacy sys¬ 
tems to or across cloud platforms. But given the widespread of the 
literature produced, a systematic support that capitalizes this body 
of knowledge to make it more explicit, reusable, and accessible is 
non-extant. 

Repeated calls by Giovanoli (2012) and Zimmermann 

et al. (2015) have remained largely unheeded for capturing and 
reusing existing cloud migration knowledge to improve decision 
making which subsequently has impact on various system quality 
goals. This article alleviates this gap via deploying a combination 
of evidence-based software engineering (EBSE) (Dyba et al., 2005) 
and goal-oriented modelling (Yu, 1997). We introduce a knowledge- 
based decision support framework that reuses the existing cloud 
migration body of knowledge for the early stage goal-obstacle 
analysis of cloud migration. The framework comprises collec¬ 
tions of repository of commonly occurring cloud migration goals, 
obstacles hindering satisfying cloud migration goals, i.e. system 
quality goals, and corresponding countermeasures to handle these 
obstacles. These collections are populated in a repository and 
have been identified through an extensive literature review of 
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published studies or experience reports in the literature. The 
evidential repository is further reused for eliciting, modelling, 
and reasoning about requirements of cloud migration scenarios. 
We believe the proposed framework helps a system architect in 
better handling of potential risks before they propagate in later 
stages and thus improving reliability of decision outcomes in 
migrating and maintaining legacy systems in cloud platforms. We 
illustrate the applicability of the framework in two scenarios of 
cloud migration. 

The rest of this article is organised as follows. Section 2 pro¬ 
vides a motivating scenario of this study. Section 3 presents the 
research methodology followed to develop and validate the pro¬ 
posed framework. Section 4 delineates the development of the 
framework components. Section 5 illustrates the application of the 
framework in two scenarios of moving legacy systems to cloud 
platforms. A review on related work in the literature in the view 
of a set of analysis criteria is discussed in Section 6. Section 7 pro¬ 
vides discussion on the benefit of using the framework which is 
followed with limitation of the framework in Section 8. Finally, 
Section 9 summarises the article with a discussion of conclusion 
and future research directions. 

2. Motivating scenario 

The uncertainty surrounding the adoption of cloud services may 
make a challenging exercise the cloud enablement of critical legacy 
systems or those that are not currently ready for transition to 
the cloud but might need to interact with other cloud-based sys¬ 
tems. The current study is inspired by a real-world cloud migra¬ 
tion scenario in oil and gas industry sector discussed in Khajeh- 
Hosseini et al. (2010) through which an IT solution organisation 
moves a legacy system from an in-house data centre to Amazon 
EC2. We call this as a migration type V discussed in Section 4.1, 
The system allows users to manage, monitor, and acquire minutely 
data from an off-shore oil rig operations located in the North 
Sea oilfields. The system comprises a database layer that logs and 
archives the data coming from offshore in a database and tape for 
taking daily database backups and business layer providing func¬ 
tionalities for data reporting and monitoring. The end users access 
the system through using a remote desktop client over the inter¬ 
net. The real time data are that coming from onshore are provided 
for users through communication links provided by the IT solu¬ 
tion organisation. The organisation has responsibility for maintain¬ 
ing and upgrading the system. 

Top level management of the organisation intends to augment 
the scale of servicing and promote its competitiveness via expand¬ 
ing their services throughout some Middle-east oil rigs. Never¬ 
theless, the organization cannot afford procurement and mainte¬ 
nance of new infrastructure to support timely processing of up¬ 
coming massive scale data from multiple oil rigs during the work¬ 
load. Cloud services attract the top level management as they are 
said to provide powerful infrastructures along with a wide-range 
of services. A system architect is appointed to design an overall ar¬ 
chitectural solution to deploy the system in Amazon EC2 Web ser¬ 
vices as a co-location to achieve higher throughput. However, she 
is unsettled with many intriguing questions being asked by the top 
level management, for example: 

(i) By moving these systems to the cloud, will higher system 
performance be attainable in all situations? 

(ii) What risks are likely to occur to obstruct reducing infras¬ 
tructure cost and system security in the cloud? and 

(iii) How such risks can be negated or at least reduced in ad¬ 
vance? 

if the system migration to cloud is to achieve its potential, this 
sort of questions should be clearly answered. The system archi¬ 


tect might have basic knowledge of promised benefits and issues 
around moving systems to the cloud. However, she may face dif¬ 
ficulty in making informed answers to the abovementioned ques¬ 
tions due to uncertainty and little objective evidence to confirm 
suitability and inherent risks of such transition. For instance, the 
choice of replacing the current relational database to a new non- 
SQL cloud database solution may have uncertain impact on the 
query processing time and thus system throughput. She may seek 
and select various information resources such as documents, we¬ 
blogs, domain expert advice, or personal experience. Due to volu¬ 
minous such sources in the cloud computing field, in particular the 
continuous growing publications since 2008 (Yang and Tate, 2012), 
it becomes more cumbersome for the system architect to grasp, 
synthesise, and reuse extant material for the given scenario since 
they may not be easy to find among the mix of other papers. 
Furthermore, she may rarely review or even have access to them. 
Solely, if they are collected, the system architect may not be able 
how to analyse these contents and envisage implications to organi¬ 
sational strategic goals. EBSE, i.e. evidence-based practice, is known 
to be one of most successful solution for an informed decision on 
a new technology adoption. In the spirit of EBSE, best evidences 
from scientific publications are capitalized by collecting, general¬ 
izing, documenting, and storing in an evidential repository which 
can be later reused for a decision making situation (Dyba et al., 
2005). In this research, we provide an evidential repository assort¬ 
ing the most evidential goals, obstacles, and countermeasures on 
how to negate them. 

Our objective is not only to develop an evidence-based repos¬ 
itory, but also to utilize the repository and incorporates its infor¬ 
mation in a suitability assessment of given cloud enablement sce¬ 
narios. Reusing the repository requires a systematic support that 
models and processes the information in the repository in asso¬ 
ciation with variety of cloud migration parameters e.g. goals, risks, 
effort, size, or calendar time. We settled on the goal-oriented mod¬ 
elling as a good candidate for exploring the repository to make in¬ 
formed answering to the abovementioned questions. It explicitly 
relates high-level cloud migration goals with potential obstacles 
and relevant countermeasures addressing these obstacles. Little or 
no research has focused on how the early stage suitability analy¬ 
sis of cloud enablement can be complemented in the presence of 
evidential data available in the field. 


3. Research methodology 

The current research pursuits crafting an IT artefact. The re¬ 
search paradigm that suits this inquiry is design science research 
(DSR) (Henver et al., 2004) in which a viable artefact addressing a 
relevant solution to an unsolved problem is developed and evalu¬ 
ated. We conducted three phases of a typical DSR, but tailored for 
the purpose of this research, as delineated in the following: 

Phase 1- Problem identification has been already described in the 
Section 1, i.e. the lack of systematic knowledge reuse to improve 
reliability of goal analysis results and decision outcomes during 
cloud enablement process. Our research objective is set up as “de¬ 
veloping of a systematic framework reusing empirical evidence for 
goal-obstacle analysis in the earliest stage of legacy system cloud 
enablement process” . 

That is, a framework reusing empirical knowledge for the goal- 
obstacle analysis in earliest stage of the cloud migration. 

Phase 2- Design and develop through which, the framework, con¬ 
stituting the following two core components, was developed: 

(i) an empirical knowledge repository of recurring goals, ob¬ 
stacles, and countermeasures in cloud enablement of legacy 
systems, 
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(ii) a procedure including steps to be taken to identify cloud 
specific goal, obstacles, assessing their risk, i.e. likelihood 
and severity, and tackling them by generating new goals. 

In the design science research, different approaches and ker¬ 
nel theories from inside or outside of the software engineering 
discipline informing an artefact creation can be brought to bear 
(Gregor and Jones, 2007). As mentioned earlier, for the develop¬ 
ment of the first component, i.e. the knowledge repository, we 
applied EBSE approach (Dyba et al., 2005). Identifying relevant ev¬ 
idence might not be an easy task, particularly in the cloud migra¬ 
tion field which publication rate is constantly growing. A common 
technique to operationalize EBSE is Systematic Literature Review 
(SLR) (Kitchenham et al., 2009) through which findings from 
different empirical scientific researches are gathered and summa¬ 
rized regarding inclusion criteria and indicators to draw plausible 
conclusions (Kitchenham et al., 2009). In this research, the frame¬ 
work’s repository has been developed out of a SLR of published 
works empirical studies in the cloud migration literature. 

For the second component, i.e. the procedure, we employed a 
generic goal-oriented modelling framework called KAOS (Keep All 
Objects Satisfied). KAOS provides support for elaborating, structur¬ 
ing and analysing software requirements, including both functional 
and non-functional ones (Van Lamsweerde, 2009). It also supports 
different levels of expression and reasoning that vary from semi- 
formal to formal analysis goal models depending on the reason¬ 
ing precision sought (Dardenne et al., 1993; Van Lamsweerde and 
Letier, 2004). In KAOS, goals are iteratively refined through top- 
down approach (by asking how questions to refine goals into sub¬ 
goals) as well as bottom-up approach (by asking why questions 
to identify parent goals). The refinement proceeds until all goals 
reach clear and assignable responsibilities to agents who can re¬ 
alize the goals. We used this modelling framework in conducting 
cloud enablement goal-obstacle analysis. 

Generic KAOS’s concepts such as goal, obstacle, and resolu¬ 
tion tactic do not provide precise definitions that can be refined 
into testable and operational cloud migration requirements. For 
example, KAOS’s concept obstacle refers to “an exceptional condi¬ 
tion that prevents a goal from being satisfied” (van Lamsweerde 
and Letier, 2000). In our view, a preliminary use of KAOS that 
specify and refine high-level goals gradually would not be suffi¬ 
cient. There is no operational definition for a refinable and testable 
cloud-related goal-obstacle analysis. We enriched KAOS’s generic 
concepts with cloud-specific knowledge that can be organized in 
an empirical repository. For instance, the generic notions of obsta¬ 
cle and resolution tactics in KAOS have been augmented with 67 
and 45 cloud-specific obstacles and resolution tactics, respectively. 
This will be later detailed in Section 4.1. 

Phase 3 - Validate appraised the efficacy of the framework re¬ 
sulting from Phase 2 through a Web-based survey and two case 
studies of moving an open-source Web-based legacy system, pro¬ 
viding real-time stock quotes, to Pivotal Cloud Foundry and a dig¬ 
ital document processing legacy system to Microsoft Azure cloud 
platform. 

DSR is an iterative develop-and-validate process in the sense 
that the developed artefact is situated in a problem space and is 
iteratively refined to fulfil quality and utility metrics (Henver et al., 
2004; Peffers et ah, 2008). In the context of this research we con¬ 
ducted in two consecutive cycles. 

The first cycle took place between February 2014 and Septem¬ 
ber 2016. It resulted in the initial version of the framework in¬ 
cluding its repository and procedure. They were both was devel¬ 
oped and validated. The framework was validated using exper¬ 
tise implicitly reflected in an SLR covering goal modelling and 
cloud computing areas. For the repository, resolution tactics were 
also validated for completeness through a comparison against ex¬ 


isting migration methods to verify if they are sufficiently com¬ 
plete (Fahmideh et al., 2016b) and through an expert review us¬ 
ing a public Web-based survey questionnaire (Fahmideh et al., 
2017). The survey examined if the resolution tactics are perceived 
as important and relevant for incorporating into the legacy sys¬ 
tem reengineering process to migrate them to cloud platforms. We 
used purposeful sampling (Patton, 1990) to identify eligible experts 
to participate from their public profiles on social media such as 
Linkedin, Twitter and academic research groups. Candidate experts 
contacted through to confirm their expertise. Once willingness and 
expertise were confirmed, an invitation along with the link to the 
survey was issued. Respondents were asked to rate the importance 
of each resolution tactic on the basis of a seven scales (1-7) where 
1 represents ‘completely irrelevant’, 2 indicates ‘unimportant’, 3 
for 'somewhat unimportant’, 4 for ‘neither important nor unim¬ 
portant', 5 for ‘somewhat important’, 6 for ‘important’, and 7 for 
‘extremely important’. 

In this voluntary survey, we invited 515 experts and 144 experts 
completed the survey. After removing incomplete responses, 104 
were used for data analysis. The respondents were from 32 coun¬ 
tries with an average of cloud migration experience of 3.8 years. 
The statistical analysis of responses revealed that the majority of 
the items in the repository were perceived sound and important 
for inclusion in the process of migrating legacy systems to cloud 
platforms. More detailed can be found in Fahmideh et al. (2017). 

In the second DSR cycle, between September 2016 and Decem¬ 
ber 2016, we extracted and adapted two real-word case studies 
available from the cloud migration literature. The first scenario 
named SpringTrader (Gordon, 2015) aimed to move an open-source 
stock screener Web-based system to Pivotal Cloud Foundry plat¬ 
form. The second scenario named InformIT (Rabetski, 2012; Rabet- 
ski and Schneider, 2013) aimed to migrate a digital document pro¬ 
cessing system to Microsoft Azure platforms. For both case stud¬ 
ies we used project documents obtained from a variety of sources, 
mainly SpringTrader’s Weblog and 43-page project documentation 
of InformIT project, to enrich our understanding of the enacted mi¬ 
gration process model including project sequence, legacy system 
and cloud solution architecture, and user histories. We traced the 
projects’ documents if and what goals each scenario defined, is¬ 
sues that were occurred and countermeasures that were applied. 
The detail description of the scenarios is presented in Section 5. 

In this article, we present the development of the framework. 
This includes the development of the repository and the procedure 
conducted in the first cycle and validating the applicability of the 
framework conducted in the second cycle. 

4. Development of the framework 

As shown in Fig. 1, the framework comprises (i) a repository 
holding empirical knowledge about collections of obstacles and 
resolution tactics, and (ii) a goal-oriented procedure relying on the 
repository in order to elaborate goal-obstacle analysis for a specific 
cloud adoption scenario. In Section 4.1, the result of the literature 
review to develop the framework repository is presented. This in¬ 
cludes establishing a literature review protocol, conducting review, 
and identifying, synthesising, and organising the collections of ob¬ 
stacles and resolution tactics. Section 4.2, a systematic procedure 
for goal-obstacle analysis is presented utilizing the information in 
the repository. 

4.3. Repository detailed design 

Three tasks were performed to develop the collections in the 
repository component of the framework: 

(i) Derivation of system quality goals expecting to be satisfied by 
migrating legacy systems to cloud environments 
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Goal-obstacle analysis procedure 



Fig. 1. Structure of the proposed framework. 



Fig. 2. SLR conducted for developing the framework repository - duration between February 2014 and September 2016. 


(ii) Derivation of recurrence obstacles against achieving quality 
goals 

(iii) Derivation of resolution tactics in handling these obstacles 

As shown in Fig. 2, a SLR was undertaken to conduct tasks (ii) 
and (iii). We did not see a need to conduct SLR for task (i) as 
we used a fixed set of system quality goals which is commonly 
agreed and deemed important in the software engineering and the 
cloud computing literature. The objective of the SLR was to answer 
the following inquiries: (i) what obstacles may occur against system 
quality goals when a legacy system is moving to or is in operation in 
cloud platforms and (ii) what resolution tactics are suggested to ad¬ 
dress the obstacles? The same SLR was conducted for tasks (ii) and 
(iii). 

4.1.1. Planning review 

The objective of this phase was to tackle any researcher bias 
(Kitchenham et al., 2009) through defining search strings, selection 
criteria, and searching databases. 

Search strings. The search strings were defined based on the 
guidelines recommended in Dieste and Padua (2007). These in¬ 
cluded: (i) defining main terms by breaking down the research 
questions, (ii) identifying alternative synonyms for main terms, (iii) 


checking the search strings in any relevant papers that retrieved, 

(iv) incorporating alternative synonyms using the logical operator 
OR, and (v) using the logical operator AND to link the main terms. 
The terms Cloud, Cloud Computing, Legacy, Migration, and laaS, PaaS, 
and SaaS were set as the main keywords from which different 
search strings defined and combined using the logical operators OR 
and AND. Table 2 shows some examples of search strings. 

Selection criteria. The following criteria were set to select stud¬ 
ies identified from the literature for purpose of the repository de¬ 
velopment. (i) the study is related to migrating legacy systems or 
developing systems for cloud platforms with a proper description 
of the context, clear objectives or research goals (ii) described situ¬ 
ations, i.e. obstacles, that may cause goal failure and if any resolu¬ 
tion tactics, (iii) provided a proper validations through case study, 
example, interview, etc., (iv) published from 2007 onwards in 
software engineering and information systems journals/conference 
proceedings: and (v) described in English language. 

Searching databases. The following databases were searched: 
IEEE Explore, ACM Digital Library, SpringerLink, ScienceDirect, Wi¬ 
ley InterScience, 1SI Web of Knowledge, and Google scholar. In 
some cases, we found that some internet blogs and trade jour¬ 
nal articles, named multi-vocal literature (Ogawa and Malen, 1991 ), 

































































Table 1 

Literature comparison addressing the evaluating of cloud computing adoption. 


Study 

Aim 

Migration type 

Lifecycle focus 

Evaluation 

granularity 

Evaluation 

approach 

Process support 

Stakeholder 

involvement 

Modelling 

language 

Experience 

repository 

Tool support 

(Anstett et al., 2009) 

Identifying factors such as operating 
system, platform middleware and 
legacy system to be considered in 
deploying BPEL on laaS. 

Type V 

Plan phase 

Legacy system 

Not specified 

Not specified 

Not specified 

Not specified 

Not considered 

Not available 

(Khajeh-Hosseini et al., 
2012) 

Providing a decision making support 
for identifying concerns in using IaaS. 

Type V 

Plan phase 

Legacy systems 

Cost modelling 

Yes 

Yes 

Deployment 
model of 
system 

Not considered 

Yes 

(El-Gazzar et al., 2016) 

Identifying inhibitors and 
organisational drivers are involved in 
a decision making for cloud 
computing adoption. 

All 

Plan phase 

Organisation 

Not specified 

Not specified 

Not specified 

Not specified 

Not considered 

Not available 

(Low et al., 2011) 

Exploring factors affecting 
organisations in adopting cloud 
computing. 

All 

Plan phase 

Organisation 

Not specified 

Not specified 

Not specified 

Not specified 

Not considered 

Not available 

(Wu et al., 2011) 

Exploring factors influencing successful 
SaaS adoption. 

Type 11 

Plan phase 

Organisation 

Decision 
making trial 
and evaluation 
laboratory 

Not specified 

Not specified 

Cause-effect 

diagram 

Not considered 

Not available 

(De Assun^ao et al., 
2009) 

Evaluating the optimality of scheduling 
strategies used by an organisation to 
reduce response time in using IaaS. 

Type V 

Enable phase 

Organisation 

Performance 

metrics 

Not specified 

Not specified 

Not specified 

Not considered 

Not available 

(Deelman et al., 2008) 

Analysing the cost-performance 
trade-off between difference 
executions and resource provisioning 
plans by legacy systems. 

Type III 

Enable phase 

Legacy systems 

Performance 

metrics 

Not specified 

Not specified 

Not specified 

Not considered 

Not available 

(Kondo et al., 2009) 

Comparing cost and performance of 
legacy systems in using IaaS. 

Type V 

Enable phase 

Legacy systems 

Performance 

metrics 

Not specified 

Not specified 

Not specified 

Not considered 

Not available 

(Walker et al., 2010) 

Reasoning about the cost of leasing 
infrastructure from cloud storage. 

Type III 

Enable phase 

Organisation 

Net present 
value 

Not specified 

Not specified 

Not specified 

Not considered 

Not available 

(Garg et al., 2011) 

Measuring, comparing, and prioritizing 
cloud services based on users’ 
requirements. 

Type V 

Enable phase 

Organisation/ 
Legacy systems 

QoS metrics 

Yes 

Implicitly 

supported 

Not specified 

Not considered 

Not available 

(Godse and 

Mulik, 2009a) 

Analysing and selecting appropriate 

SaaS products. 

Type II 

Enable phase 

Organisation 

AHP 

Embedded in 

framework 

description 

Implicitly 

supported 

Not specified 

Not considered 

Not available 

(Menzel et al., 2013) 

Examining if IaaS meets organisation 
needs by evaluating and ranking 
alternatives using a set of criteria 
catalogue. 

All 

Enable phase 

Organisation/ 
Legacy systems 

ANP 

Yes 

Implicitly 

supported 

Not specified 

Not considered 

Yes 

(Scandurra et al., 2016) 

Redeploying e-commerce cloud 
applications on different servers at 
run-time based on evolving 
requirements, sudden changes in the 
operational environment conditions, 
and application traffic. 


Maintain phase 

Legacy systems 

Goal reasoning 

Embedded in 

framework 

description 

Not specified 

Graph 

modelling 

Not considered 

Not available 

(Nikkhouy, 2013) 

Exploring potential benefits and risks 
in migrating legacy systems to cloud 
services. 

All 

Plan phase 

Organisation 

Change analysis Yes 

Implicitly 

supported 

Cause and 
effect diagram 

Not considered 

Not available 

(Christoforou and 
Andreou, 2013) 

Assessing the feasibility of the cloud 
adoption in organizations regarding 
factors such as security, legal issues, 

All 

Plan phase 

Organisation 

Analysing 

influencing 

factors 

Embedded in 

framework 

description 

Yes 

Influence 

diagrams 

modelling 

Not considered 

Not available 


availability, cost, ROI, compliance, 
performance, scalability, and data 
access/import-export. 


(continued on next page ) 
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Table 1 ( continued ) 


Study 

Aim 

Migration type 

Lifecycle focus 

Evaluation 

granularity 

Evaluation 

approach 

Process support 

Stakeholder 

involvement 

Modelling 

language 

Experience 

repository 

Tool support 

(Tak et al„ 2011) 

Exploring factors such as workload 
intensity, growth rate, storage 
capacity and software licensing costs 
affecting the cost of deployment 
options in the cloud. 

V 

Plan phase 

Legacy systems 

Using 

benchmarks 
representing of 
different 
scenarios 

Not specified 

Not specified 

NPV models 

Not considered 

Not available 

(Juan-Verdejo and 

Baars, 2013) 

Identifying suitable components of 
legacy systems for deploying on IaaS 
with respect to interdependencies 
among components and factors such 
as data transfer volumes, 
performance, sensitivity of 
cloud-based data repositories, and 
exposure to public networks. 

V 

Enable phase 

Legacy systems 

Combination of 
scenario based 
& AHP 

Embedded in 

framework 

description 

Yes 

Legacy system 

architecture 

model 

Not considered 

Not available 

(Menzel and 

Ranjan, 2012) 

Identifying a compatible combination 
of software images (e.g., Web server 
image) in mapping web applications 
to virtualized cloud services while 
expected QoS of applications are 
satisfied. 

V 

Enable phase 

Legacy systems 

Combination of 
optimization 
and AHP 

Embedded in 

framework 

description 

Yes 

Simulation 

models 

Not considered 

Not available 

(Fittkau et al., 2012) 

Evaluation of competing cloud 
deployment options and finding the 
most suitable mapping of virtual 
machines to cloud services regarding 
cost and system performance. 

V 

Enable phase 

Legacy systems 

Combination of 

optimization 

and 

scenario-based 

Yes 

Yes 

Simulation 

models 

Not considered 

Not available 

(Saripalli and 

Pingali, 2011) 

Ranking legacy system workloads for 
migrating to cloud environments 
based on attributes such as latency, 
bandwidth, and cost. 

All 

Enable phase 

Legacy systems 

Combination of 

multi-attribute 

decision 

making and 

wide-band 

Delphi 

Embedded in 

framework 

description 

Yes 

Decision matrix 

Not considered 

Not available 

(Calheiros et al., 2011) 

Determining the best deployment 
options of components of legacy 
systems on cloud servers whilst QoS 
are satisfied. 

V 

Enable phase 

Legacy systems 

Scenario-based 

Embedded in 

framework 

description 

Yes 

Simulation 

models 

Not considered 

Yes 

(Leymann et al, 2011) 

Rearrangement of the legacy 
application deployment topology on 
cloud servers regarding dependencies 
among its components and 
requirements such as latency, 
transfer, and data privacy are 
addressed. 

V 

Enable phase 

Legacy systems 

Optimisation 
algorithm (e.g. 
simulated 
annealing) 

Yes 

Not specified 

Metamodeling, 

application 

templates 

Not considered 

Yes 

(Giovanoli, 2012) 

Assessing and selecting the most 
suitable cloud services via guidelines 
provided in a database containing 
information of different cloud service 
providers. 

All 

Enable phase 

Legacy systems 

Not specified 

Not specified 

Not specified 

Not specified 

Information 
repository of 
cloud service 
providers 

Yes 

(Zardari et al., 2014) 

Prioritising obstacles related to cloud 
service adoption and resolution 
tactics. 

All 

Plan phase 

Legacy systems 

Goal reasoning 
and AHP 

Yes 

Yes 

Goal models 

Not considered 

No 

This work 

Analysing goal-obstacle in migrating 
legacy systems to cloud platforms 
along with resolution tactics which 
utilizes an evidence-based repository 
during the steps of the goal-oriented 
elaboration process. 

All 

Plan and enable Legacy systems 
phases 

Goal reasoning 
and 

evidence-based 

approach 

Yes 

Yes 

Goal models 

Yes 

No 


M. Fahmideh, G. Beydoun/The Journal of Systems and Software 138 (2018) 124-157 





130 


M. Fahmideh, C. Beydoun/The Journal of Systems and Software 138 (2018) 124-157 


Table 2 

list of related search strings (SS). 

SSI: “Migration" OR “Cloud adoption" OR “Cloud migration" OR “Migration 
to cloud" OR "Legacy to cloud migration” OR “Legacy migration to cloud” 
AND [SS2 OR SS3 OR SS4 OR SS5 OR SS6] 

SS2: “IaaS risks” OR “IaaS challenges” OR “laaS challenges” OR “IaaS 
adoption” OR "IaaS benefits” 

SS3: "PaaS risks” OR “PaaS challenges” OR "PaaS issues” OR “PaaS 
adoption” OR "PaaS benefits" 

SS4: “SaaS risks” OR “SaaS challenges" OR "SaaS issues” OR "SaaS 
adoption" OR “SaaS benefits” 

SS5: “Monolith application" OR “Legacy code” OR "Legacy system” OR 
“Existing system” OR “Legacy component” OR “Legacy software” OR 
“Legacy application” “On-premise application” OR “Monolithic system" 

OR “Existing software” OR "Pre-existing software” OR “Legacy 
information system” OR "Legacy program" OR “Pre-existing assets” OR 
"Legacy architecture” OR “Legacy asset” 

SS6: “Motivation” OR “Benefits" OR “Advantage” OR "Disadvantage" OR 
“Goal” OR "Objective” 


provided empirical accounts of issues surrounding legacy system 
migration to cloud platform. These sources were not overlooked to 
search. 

4.1.2. Conducting review 

Study selection. The databases numerated in the previous step 
were searched using the search strings. The title, abstraction, and 
in the most cases the content of each study was screened regard¬ 
ing the inclusion criteria. It is important to mention that conduct¬ 
ing the review was not a linear and mechanical process; rather 
it was a hermeneutic, iterative, and informed by careful reading 
each study and understanding its context. Forward and backward 
searches were performed so that the studies cited in the refer¬ 
ences and related work sections of the study were fed into the 
review process as new resources. The review phase, strictly speak¬ 
ing is open ended, resulted in identifying 112 studies as shown in 
Appendix A. 

Data extraction, analysis, and aggregation. Segments of each 
study that stated any obstacles or resolution tactics were extracted 
along with the reference to the study. Some leading questions that 
are used during the development of the collections were the fol¬ 
lowing: (i) does the study report any technical or social obstacles 
that may cause cloud adoption goals fail? If so, what is the ob¬ 
stacle? (ii) how can the obstacle influence the successful adoption 
of cloud services? and (iii) Are there any resolution tactics sug¬ 
gested by study to overcome the obstacles? All collections obtained 
through this step presented in Appendix B. A synopsis is provided 
here in what follows: 

(i) Goals collection includes ten ready-made common software 
system quality goals that cloud services can positively con¬ 
tribute to the efficiency of working legacy systems. This in¬ 
cludes Availability, Scalability, Security, Performance, Customiz¬ 
ability, Interoperability, Portability, Testability, Consistency, and 
Reduced IT cost. These goals facilitate initialization and re¬ 
finement of goal models as described Section 4.2. 

(ii) Obstacles collection has information about 67 common 
probable situations causing quality goal failure and thus 
hampers legacy systems benefit from cloud services. The col¬ 
lection of obstacles, which can be technical or social, their 
associations to quality goals and variants of cloud adoption 
are presented in Appendix B. 

(iii) Resolution tactics collection contains 45 platform-agnostic 
solutions applicable for handling obstacles. Resolution tactics 
are a result of applying abstraction and synthesisation on 
existing ad-hoc implementation techniques to utilize cloud 
service available in the literature. They are used during the 
goal-obstacle analysis to explore alternative ways to resolve 


identified obstacles. Note that this research tended to keep 
resolution tactics at the abstract level. Thus their opera¬ 
tionalization details are left to system developers or man¬ 
ager as to existing supportive techniques or tools available 
in the cloud computing marketplace. Appendix B lists all the 
tactics. 

Based on the common service delivery models IaaS, SaaS, and 
PaaS, several variants can be considered through which legacy sys¬ 
tems can utilize cloud services. In Fahmideh et al. (2016) these 
types are defined as follows. In Type I the business logic layer 
of a legacy system, which offers discrete and reusable function¬ 
ality, is deployed in the cloud infrastructure through IaaS model 
such as Amazon EC2 but the data layer is maintained using an 
on-premises network. In Type II, legacy system components are re¬ 
placed with a fully tested cloud services using SaaS model. In Type 

III, the database of a legacy system is deployed on a cloud data 
store provider such as Amazon Simple Storage Service (S3), Ama¬ 
zon Elastic Block Store, Dropbox, or Zip Cloud whilst business logic 
components are maintained on an on-premises network. In Type 

IV, the database of a legacy is modified and converted to a cloud 
database solution such as Amazon SimpleDB, Google App Engine 
data store, or Google Cloud SQL. Finally, in Type V the whole legacy 
system stack is encapsulated in virtual machines and then ran in 
the cloud infrastructure. 

Adopting each of abovementioned migration types may raise 
some obstacles. For example, it is quite common for incompati¬ 
bility issues between legacy system data type and a chosen cloud 
database solution to arise in the case of adopting migration types 
I, II, IV, and V. To indicate such situations, the collection of obsta¬ 
cles in Appendix B shows if an obstacle is related to a migration 
type via symbols ^/. During step 2.1 of the obstacle analysis, this 
information is used to identify obstacles. 

Results. Table 3 shows an excerpt of the information stored in 
the repository. A goal, obstacle, and resolution tactic is respec¬ 
tively denoted by an identifier-number G, 0, and T. For example, 
the quality goal for a system is that it should be interoperable (G6) 
across different platforms. According to the cloud computing lit¬ 
erature [S2], [S3], [S4], [S5], [S35], [S36], and [S37], cloud services 
can typically be integrated into a system through either brokering 
or cloud interfaces. Nevertheless, there are some potential obsta¬ 
cles which obstruct this quality goal. These obstacles, for exam¬ 
ple, as reported in [S23], [S24], [S12], [S38], [S25], [S26], [S27], 
[S39], and [S40] are Incompatible pluggable cloud services (019), In¬ 
complete APIs (020), Incompatible datatypes (021), Operating system 
incompatibility (022), and Machine-image incompatibility (023). In 
addressing these potential obstacles, two generic tactics Refactor 
legacy source code (T2) and Develop adaptor/wrapper (T3) are sug¬ 
gested in [S65], [S66], [S67], [S75], [S76], Maintaining consistency, 
the architect may slightly change the original names of these goals, 
obstacles, and resolution tactics for simplifying modelling. 

4.2. Establishing a procedure for goal-obstacle analysis 

As mentioned earlier, this research uses KAOS modelling con¬ 
cepts to elicit, model, and reason about goals for migrating legacy 
systems to cloud platforms in a precise and systematic way. 
However, as KAOS modelling concepts are generic, we enriched 
these concepts by introducing 67 obstacles and 45 tactics. Table 4 
presents KAOS modelling concepts used for representing cloud re¬ 
lated goals, obstacles, and tactics. 

Our KAOS-based procedure includes the following two steps: (i) 
Set-up cloud migration goals to set up and visualize high-level qual¬ 
ity goals targeted for moving legacy systems to the cloud, (ii) Anal¬ 
yse obstacles comprising sub-steps for identifying obstacles caus¬ 
ing goal failure, assessing their risk, and defining resolution tac- 
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Table 3 

An excerpt of probable obstacles obstructing the quality goal system interoperability 
along with some alternative resolution tactics and reference to the empirical stud¬ 
ies. 


Quality goal 

Definition 

Source 

G6 

Interoperability. Various cloud services can be 
inimitably incorporated to and integrated 
with the system as required. 

Genera 
literature 
on cloud 
computing 
(e.g. [S2], 

[S3], [S4], 

[S5], [S35], 
[S36], [S37] 

Obstacle 

Definition 

Source 

019 

Incompatible pluggable cloud services. At 

runtime, system might be plugged to a cloud 
service which is incompatible with the other 
cloud services. 

[S23] 

020 

Incomplete APIs. Cloud service provider lacks 
providing a rich set of APIs. 

[324] 

021 

Incompatible data types. Data types used in 
legacy and cloud service are incompatible. 

[S12], [S38] 

022 

Operating system incompatibility. System 
components are distributed and moved 
among cloud servers with different operating 
systems which might be incompatible for 
managing, representing, and formatting 
virtual machines. 

[325], 

[S26], [S27] 

023 

Machine-image incompatibility. Virtual 
machines are moving between different 
cloud platforms but each platform has 
different underlying implementation for 
virtual machines. 

[S39], [S40] 

Resolution 

tactic 

Definition 

Source 

T5 

Refactor legacy source code. Adapt the source 
code for being compatible and able to 
interact with the selected cloud platform 
programming language and APIs. 

[565] , 

[566] , [S67] 

T3 

Develop adaptor/wrapper. Add adaptors for 
resolving mismatches, occurring at runtime 
system execution, between legacy system 
components and cloud services. 

[S75], [S76] 


tics to modify existing goals, or generating new ones to prevent, to 
reduce, or to mitigate the obstacles. The output of the procedure 
provides for a system architect a consolidated requirement model 
in which cloud migration goals are elaborated with potential ob¬ 
stacles to be tackled, assumptions, alternative resolution tactics to 
eliminate, alleviate, or avoid obstacles. This model is later incorpo¬ 
rated into the process of migrating or developing systems for cloud 
environments. 

To illustrate the inner working of the procedure, an example 
scenario of moving the database of a legacy system to the cloud 
service Amazon Simple Storage (S3) (AmazonS3) (a public, secure, 
and highly scalable data storage) is described. This is an instance 
of migration type V. 

Step 1 Set-up cloud migration goals 

The framework provides a collection of quality goals commonly 
intended in moving existing legacy systems to the cloud that 
a system architect and other stakeholders can use to initiate a 
goal model. In under study example, three goals are set for mov¬ 
ing the legacy system database to S3 platform (Fig. 3). This in¬ 
cludes Achieve [Reduced IT cost], Achieve [Improved performance], 
and Achieve [Improved availability]. Goals can be refined into fine 
granular ones for more accurate analysis using AND/OR decompo¬ 
sition. An AND-refinement means that satisfying top goal depends 
on satisfying all sub-goals. OR-refinement presents a set of alter¬ 
native goals in which satisfying top goal can be realized by satis¬ 
fying one of alternative goals (Cailliau and van Lamsweerde, 2013). 
Using AND-refinement mechanism, the goal Achieve [Improved per- 


Table 4 

Notations used for goal modelling. 

Modelling Definition Graphical notation 

element 


Migration type 


Goal 


Obstacle 


Resolution 

tactic 


AND/OR 

Decomposition 

Contribution 


An option through which legacy 
systems can benefit from cloud 
services to improve their working 
performance (See Section 2). 

A quality goal that is expected to be 
satisfied by utilizing cloud services. 

A technical or a none-technical 
exceptional situation/condition 
preventing the goal satisfaction. 

A generic solution to resolve an 
obstacle by introducing new goals, 
assumptions, or by modifying 
existing goals. 

A mechanism to refine goals model to 
a set of fine-grain goals/obstacles. 

Positive contribution a migration type 
to a quality goal. 




\_1 


-V 


formance] is a combination of sub-goals Achieve [Reduced data up¬ 
loading time] and Achieve [Reduced query processing time] meaning 
that the satisfaction of Achieve [Improved performance] depends on 
the satisfaction of both these sub-goals. In Fig. 3, the dotted ar¬ 
rows show the fact that goals, obstacles, and resolution tactics are 
extracted from the repository. 

Step 2 Analyse obstacles 

Generally, goals are viewed idealistic and overlook unexpected 
behaviours of real environment may cause their failures (van Lam¬ 
sweerde and Letier, 2000; Letier, 2001). Taking a pessimistic view 
to a goal model, such situations, referred to them as obstacle, 
should be systematically detected, assessed, and handled in the 
early stage of migration and if needed goals should be modi¬ 
fied (Letier, 2001). Obstacles are a dual notion to goals meaning 
that as goals capture desired conditions, obstacles capture undesir¬ 
able conditions (Letier, 2001). The framework defines an iterative 
identify-assess-resolve cycle as follow: 

(i) Systematic identification of obstacles that may impede the 
satisfaction of goals (Step 2.1); 

(ii) Assess risk of obstacles in terms of likelihood and criticality 
(Step 2.2); and 

(iii) Resolve obstacles by modifying existing goals or generating 
new ones so as to prevent reduce or mitigate the obstacles 
(Step 2.3). 

Step 2.1 Identify obstacles 

To refine a goal model to obstacles, the system architect can 
identify obstacles in two ways: 

(i) Evidential where the probable obstacles are identified from 
the repository. For each quality goal, the system architect 
reviews the collection of obstacles and shortlists probable 
ones. This is mainly based on in on information provided by 
developers, user experience, and statistics about legacy sys¬ 
tems, and available accounts about cloud services. 

(ii) Domain-based where the obstacle is domain specific and 
in fact a refinement of an existing obstacle in the reposi¬ 
tory. Domain-specific obstacles are means to refine the goal 
model to new sub-obstacles. 

Similar to goal elements, AND/OR operators are used to re¬ 
fine obstacles to sub-obstacles. AND-refinements includes a com¬ 
bination of sub-obstacles causing the parent obstacle whilst, OR- 
refinements result in a set of alternative sub-obstacles may occur 
separately (Letier, 2001). Fig. 4 shows an example of a generated 
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Fig. 3. Goals in moving the legacy system database to Amazon S3. 


goal model as the output of this step. The goal Achieve [Reduced 
data uploading time] is obstructed by the obstacles Performance 
variability of Amazon S3 (027) and Geographical distance (028). The 
root obstacle Performance variability of Amazon S3 (027), which is 
suggested by the repository, is refined into two domain-specific 
obstacles High uploading time for blobs datatype (100k entries) 
(027_i) and Low throughput to write buckets (027_2). Moreover, 
the goal Achieve [Improved availability] is obstructed by the obsta¬ 
cles Service transient fault (03) and Cloud outage (01). The obstacle 
Cloud outage (01), by itself, is refined into three sub-obstacles Lo¬ 
cal network disruption (OI_l), I/O issues of servers (01_2), and S3 
data centre outage (01_3) that are domain-specific refinements of 
the obstacle Cloud outage (01) suggested by the repository. The do¬ 
main specific obstacle S3 data centre outage (01_3) is also refined 
into two obstacles Local electrical storm (01_3_1) and S3 power out¬ 
age (01_3_2). 

Step 2.2 Assess obstacles 

Analysing the risk or criticality of obstacles identified in Step 
2.1 is important to get an understanding of requirements for mak¬ 
ing a legacy system cloud enabled. The framework uses the stan¬ 
dard qualitative technique Risk Analysis Matrix (RAM) devised by 
the acquisition reengineering team at the Air Force Electronic Sys¬ 
tem Centre (Franklin, 1996). The qualitative expression of obstacle 
risks in RAM is suitable when precise numerical methods are not 
difficult to find or not required. In this technique the likelihood 
of an obstacle is judged by qualitative scales from Almost Certain, 
Likely, Possible, Unlikely, and Rare and the consequence of the oc¬ 
currence of an obstacle is represented by Insignificant, Minor, Mod¬ 
erate, Major, and Catastrophic. The risk associated with an obstacle 
is defined as the product of its probability of occurrence and sever¬ 
ity (i.e. Risk = Likelihood x Consequences). These qualitative scales 
measure the likelihood of an obstacle occurrence and its associ¬ 
ated consequences. A risk matrix can be created to highlight the 
risk zone as shown in Table 5. An organization may define zones 
as generally unacceptable, acceptable, or low-risk. For example, the 
risk of an obstacle might be perceived as moderate (M) but it is 


Table 5 

risk matrix for obstacles. 


Likelihood 

Consequence severity 




Insignificant 

Minor 

Moderate 

Major 

Catastrophic 

Almost Certain 

H 

H 

E 

E 

V 

Likely 

M 

H 

H 

E 

V 

Possible 

L 

M 

H 

E 

E 

Unlikely 

L 

L 

M 

H 

E 

Rare 

L 

L 

M 

H 

H 


V: Very extreme risk, E: Extreme risk; H: High risk; M: Moderate risk; L: Low risk. 


still tolerable whilst an obstacle with H (High) and E (Extreme) 
should be handled more carefully. 

Note that, calculating the product of likelihood and conse¬ 
quence of obstacles in this example shown in Table 5 relies on 
the availability of information sources such as the specification of 
cloud service providers, statistics from legacy systems, developers, 
end-users’ experience, and an overall impact of risks on goals. The 
system architect may use a voting mechanism involving various 
stakeholders to accurately estimate the occurrence likelihood and 
their consequences. Hence, the values in Table 5 are actually com¬ 
puted reflecting the domain information in a goal-obstacle analysis 
scenario. 

Step 2.3 Resolve Goal Obstacles 

Obstacles whose risks are recognized serious enough, (e.g. very 
extreme, extreme, and high risk) must be tackled (van Lamsweerde 
and Letier, 2000; Letier and Van Lamsweerde, 2004). The frame¬ 
work relies on the knowledge repository that provides a cata¬ 
logue of resolution tactics to address obstacles identified in the 
previous step. Obstacle resolution tactics are known to be tech¬ 
nological independent in a way that the system architect can 
freely seek a wide range of tactics and to negotiate them with 
the stakeholders. In our framework, resolution tactics are cloud 
platform agnostic but varying among seven categories: namely 
Goal/Service/Migration type Substitution, Obstacle prevention, Obsta- 
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Fig. 4. Obstacles against achieving quality goals Achieve [Reduced IT cost], Achieve [Improved performance], and Achieve [Improved availability] retrieved from the repository. 


cle reduction, Goal weakening, Goal restoration, Goal mitigation, and 
Do nothing (Appendix B). Resolution tactics are platform agnostic 
to give system developers freedom to have a broad ranges of tech¬ 
niques to operationalize them. Their full definitions are presented 
in Appendix B. In this superficial example, all the obstacles are as¬ 
sumed sever and thus the goal model is refined by resolution tac¬ 
tics used to handle the obstacles (Fig. 5). For instance, to reduce 
the occurrence likelihood of obstacle Geographical distance (028), 
the system architect chooses the resolution tactics Refine network 
topology (T24) from the repository. Another example is the reduc¬ 
ing the risk of obstacles High uploading time for blobs (100k entries) 
(027_l) and Low throughput to write buckets (027_2) through in¬ 
corporating the resolution tactic Use multiple cloud servers (T27) in 
the new architecture of the legacy system. 

5. Application of the framework in practice 

This section presents two case studies as a benchmark for the 
validation of the framework. In these scenarios migration types 
V and IV are performed. The first case was a scenario of mov¬ 
ing an open-source Web-based system providing real-time stock 
quotes for users to a private cloud platform. The second scenario 
was about moving a Web-based system for processing digital doc¬ 
uments to a public cloud. The system architect used domain in¬ 


formation related to the migration scenario as the main source to 
selected and shortlisted the pre-constructed collection of obstacles 
and resolution tactics. In both scenarios, the risk matrix values pre¬ 
sented in Table 5 were used to assess obstacle risk. 

5.1. Case study 1 

SpringTrader (Gordon, 2015) is an open-source Web-based sys¬ 
tem that enables users to create account and browse stock port¬ 
folio, lookup stock quotes, and buy and sell stock shares. It has 
been developed using J2EE framework and maintained by many 
contributors over time. SpringTrader architecture includes (i) Web- 
based layer enable users for browsing stock quotes and portfolios, 
lookup stock quotes, and ordering stock trade orders and (ii) a 
backend that fulfils orders. The communication between the web- 
based frontend and the backend is a-synchronous where the front- 
end delivering orders to a message queue and the back-end pro¬ 
cessing them. 

Moving SpringTrader to Pivotal Cloud Foundry which is an open 
source platform for developing and deploying full stack software 
systems in the cloud would enable users to utilize this powerful 
cloud platform to access real-time stock market data in a more 
interactive way with the system as well as the individual scaling 
up/down of system components. The system architect was inter- 
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Fig. 5. Resolution tactics to tackle obstacles. 


ested in analysing architectural requirements in enabling Spring- 
Trader to operate in this platform. The documentation of this 
project is available at (Gordon, 2015). 

Step 1 Set-up cloud migration goals 

A goal model was created with the three initial goals Achieve 
[Increased scalability], Achieve [Keeping system interoperable], and 
Achieve [Keeping system available] with the following specifications: 

Goal Achieve [Increased scalability] 

Definition [Moving the SpringTrader to the cloud should make 
it scalable in the sense that the system should be able to 
service massive end users’ requests during workload] 

Goal Achieve [Keeping system interoperable] 

Definition [The SpringTrader should be integratable with and be 
able to call cloud services] 

Goal Achieve [Keeping system availability] 

Definition [Moving the SpringTrader to the cloud should not af¬ 
fect the system availability to end users] 

Step 2 Analyse obstacles 

Step 2.1 Identify obstacles. Reviewing the architecture model 
of SpringTrader revealed that the tight dependencies among sys¬ 
tem component impede their individual scalability and portabil¬ 
ity across multiple instances of servers. This was an instance of 


the obstacle Tight dependencies (051) against the goal Achieve [In¬ 
creased scalability]. For new platform, it was planned to use cloud 
database solutions such as MySQL and MongoDB for the Spring- 
Trader. However, they were incompatible with the SQL database 
of SpringTrader. This was indeed an obstacle to the goal Achieve 
[Keeping system interoperable], an instantiation of the root obsta¬ 
cle Incompatibility of legacy data storage and cloud (049) defined in 
the repository. This obstacle, by itself, was refined into two obsta¬ 
cles Incompatible data operations (050) and Incompatible data types 
(021). Another obstacle to the goal Achieve [Keeping system inter¬ 
operable[ was that SpringTrader had been implemented using Java 
Development Kit 6 and Spring 3 that accordingly are not compat¬ 
ible with their equivalent (i.e. Java Development Kit 8 and Spring 
4) in the Cloud Foundry platform. Integrating the SpringTrader with 
the Quote Web-Service, a service using the public Yahoo Finance 
APIs to provide real-time market data, would raise the risk of ser¬ 
vice unavailability as this service is hosted on the Cloud Foundry 
servers and geographically out of the local network of SpringTrader. 
This domain information confirmed that the obstacle Service tran¬ 
sient fault (03) would likely to occur against the goal Achieve [Keep¬ 
ing system availability]. The goal model was updated with new four 
obstacles shown in Fig. 6. 
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Fig. 6. Goals Achieve [Increased scalability!, Achieve [Keeping system interoperable!, an d Achieve [Keeping system availability! refined to four obstacles informed by the framework 
repository. 


Table 6 

Risk matrix for the obstacles identified from Step 2.1. 


Obstacle against quality goal 

Likelihood 

Consequence 

Risk 

Tight dependencies (051). SpringTrader 
components have tight dependencies 
to meta-libraries that are sometimes 
dependencies that are incompatible 
with JDK 8. This cause the 
component of the system cannot be 
scalable and portable across multiple 
instances of servers. 

Almost Certain 

Major 

E 

Incompatible data operations (050). 
Various SQL statements in 
SpringTrader related to manipulating 
records are not syntactically and 
semantically compatible with 
corresponding MongoDB statements 
and MySQL provided by Pivotal 

Cloud Foundry platform. 

Almost Certain 

Major 

E 

Incompatible data types (021). In some 
cases data types (e.g. length and 
format) used in SpringTrader 
database are not compatible with 
corresponding ones in MySQL and 
MongoDB. 

Almost Certain 

Major 

E 

Service transient fault (03). Quote 
Web-Service might be temporarily 
unavailable for reasons such as 
network traffic load or server 
workload. 

Possible 

Minor 

L 


Step 2.2 Assess obstacles. The occurrence probability and the 
consequence of the obstacles identified from step 2.1 were as¬ 
sessed according to the domain information such as developers 
and end users’ opinions and statistics about SpringTrader. Table 6 


shows the risk matrix of obstacles. The goal Achieve [Increased 
scalability] was refined to the obstacle Tight dependencies (051) as 
shown in Fig. 7. Based on the architecture model of legacy system, 
the occurrence likelihood of this obstacle is Almost Certain. This 
was also true for the obstacles Incompatible data operations (050) 
and Incompatible data types (021) since SpringTrader database was 
incompatible with the Pivotal Cloud Foundry platform. 

The occurrence likelihood of obstacle Service transient fault (03) 
was found Possible as it could be situations in which SpringTrader 
components could not successfully call Quote Web-Service in the 
first attempt due to transient faults in making network connection 
to Quote Web-Service hosted in servers in Pivotal Cloud Foundry 
platform. Although it was a violation from the goal Achieve [Keep¬ 
ing system available], its consequence was believed Minor. There¬ 
fore, the risk of this obstacle was set Low. 

Step 2.3 Resolve goal obstacles. The system architect explored 
the repository to find the catalogue of resolution tactics han¬ 
dling obstacles for incorporation into new architecture of Spring- 
Trader reengineered to operate in Pivotal Cloud Foundry platform. 
The system architect selected the resolution tactic Decouple sys¬ 
tem components (T7) from the category Obstacle prevention (see 
Appendix B) to remove obstacle Tight dependencies (051). The tactic 
used to operationalise was implementing a mediator and synchro¬ 
nisation mechanisms to manage interaction between the system 
components each deployed in different servers of Pivotal Cloud 
Foundry platform. For the obstacles Incompatible data operations 
(050) and Incompatible data types (021) the architect used the 
tactics Adapt data (T12) and Develop adaptor/wrapper (T6), respec¬ 
tively. The former is to convert data types of SpringTrader into the 
data type of database solutions, i.e. MySQL and MongoDB, offered 
by the Pivotal Cloud Foundry platform whilst the latter is to add 
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Fig. 7. Resolutions tactics for handling obstacles. 


adaptors/wrappers that are responsible for runtime conversion of 
SpringTrader operations into the Pivotal Cloud Foundry. 

To reduce the probability occurrence of the obstacle Service 
transient fault (03), the adopted resolution tactic was Define retry 
policies (T23) which is subsumed under the group Goal Restora¬ 
tion. That is, implementing a retry policy in the architecture of 
SpringTrader to specify the delay before executing the next attempt 
for connecting to the Pivotal Cloud Foundry server when transient 
faults occur due to network congestion. In addition, the system ar¬ 
chitect chose the tactic Replicate system components (Ti8) from the 
group Obstacle Prevention group. The tactic is to partition, replicate, 
and distribute components and data (replicas) of SpringTrader over 
multiple servers of Pivotal Cloud Foundry. 

Resolution tactics defined in the framework repository are 
generic recurrent solutions that can be operationalized using dif¬ 
ferent implementation techniques or tools available in the cloud 
computing marketplace. For example, in this scenario the reso¬ 
lution tactic Develop adaptor/wrapper (T6), addressing incompati¬ 
bilities between a legacy system database and a cloud database 
solution, is operationalized using the notion of bounded context 
(Thones, 2015) in the sense that the transition of data is packed 
and unpacked during the executing of transactions. As another ex¬ 
ample, to realize the tactic Decouple system components (T7), devel¬ 
opers used micro-service architecture design (Dragoni et al„ 2016) 
along with a service discovery mechanism to enable SpringTrader 
to locate micro services by name at a known catalogue endpoint 
and look them up dynamically at runtime. Fig. 7 shows the resolu¬ 
tion tactics selected in this scenario. 

In Table 7, the first and second columns, respectively, show the 
resolution tactics and their operationalisation techniques used to 
handle obstacles presented in third column. 

5.2. Case study 2 

The second case is adapted from the scenario presented in 
Rabetski (2012) and Rabetski and Schneider (2013). InformIT is a 
small independent software vendor in Sweden providing a Web- 


Table 7 

Resolution tactics to handle obstacles in migrating SpringTrader to Pivotal Cloud 
Foundry. 


Resolution tactic 

Operationalisation 

Relation to 
obstacle 

Decouple system 

Decouple the SpringTrader components 

Tight 

components (T7) 

from each other by using mediator 
enabling a- synchronised interaction 
among loosely coupled components 
in deployed on distributed 
architecture of Pivotal Cloud Foundry. 

dependencies 

(051) 

Develop adap- 

Develop adaptor component in 

Incompatible 

tor/wrapper(T6) 

SpringTrader to emulate operations 
are supported in MySQL and 

MongoDB and map mismatches 
between datatypes in SpringTrader 
and Pivotal Cloud Foundry. 

data operations 
(050) 

Adapt data (T12) 

Implement a mapping table to convert 
incompatible data types in 
SpringTrader and MySQL and 
MongoDB. 

Incompatible data 
types (021) 

Replicate system 

Partition, replicate, and distribute the 

Service transient 

components 

(T18) 

Define retry 
policies (T23) 

components of SpringTrader on 
multiple servers of Pivotal Cloud 
Foundry. 

Implement retry policies in the source 
code of SpringTrader to specify the 
delay before executing the next 
attempt when Pivotal Cloud Foundry 
does not respond. 

fault (03) 


based digital document processing (DDP) legacy system offers pub¬ 
lishing services to medium and large companies who have ade¬ 
quate infrastructure to perform these resource-demanding services. 
Small companies were interested in taking the advantages of DDP’s 
services. However, they could not afford the financial commitment 
to procure new infrastructure, charging per user and installation to 
use DDP. InformIT believed that DDP’s services could be also used 
by small companies without the need for upgrading infrastructure 
if they instead would deploy and run on the cloud via migration 
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Fig. 8. Refined the goals Achieve [Improved performance], Achieve [Improved testability], Achieve [Reduced cloud adoption cost], Achieve [Improved portability] to leaf obstacles. 


types V and IV. The history of goal-obstacle analysis conducted by 
system architecture regarding reengineering DDP is described in 
the following. 

Step 1 Setting-up cloud adoption goals 

The cloud enablement scenario should not exceed 90 days. This 
is represented via the goal Achieve [Reduced cloud adoption cost] 
and its specification is: 

Goal Achieve [Reduced cloud adoption cost] 

Definition [According to InformIT policy, the latest completion 
time for any new technology adoption for small companies 
should not exceed more than 90 days. In this scenario, mov¬ 
ing the DDP to the cloud should be fulfilled with minimum 
development effort]. 

In addition to the above, goals Achieve [Improved performance], 
Achieve [Improved testability], and Achieve [Improved portability] 
were set to be satisfied by moving the DDP to a cloud platform. 
For example, the goal Achieve [Improved performance] is defined: 

Goal Achieve [Improved performance] 

Category Performance Goal 

Definition [acceptable system throughput for rendering a digi¬ 
tal document with any size should be no more than 4.9 sec¬ 
onds]. 

Step 2 Analyse obstacles 

Step 2.1 Identify obstacles. In view of domain information, 
scanning the framework repository refined the top goals towards 
root obstacles and subsequently leaf ones. The result is shown in 
Fig. 8. For example, there were two probable obstacles Learning 
curve (033) and Incompatibility of legacy and cloud service (048) 
against the satisfaction of the system goal Achieve [Reduced cloud 
adoption cost]. Moreover, experience of developers confirmed that 
the goal Achieve [Improved performance] might be obstructed by the 
performance variability of cloud servers once DDP is in operation 


Table 8 

Risk matrix for the obstacles identified from Step 2.1. 


Obstacle 

Likelihood 

Consequence 

Risk 

Performance variability of cloud servers 

Likely 

Major 

E 

(027) 

State based dependency (029) 

Likely 

Moderate 

H 

Low middleware performance (029) 

Likely 

Moderate 

H 

Browser latency (046) 

Likely 

Moderate 

H 

Incompatibility of legacy and cloud 

Almost Certain 

Major 

E 

service (048) 

Learning curve (033) 

Almost Certain 

Major 

E 

Backward incompatibility (042) 

Likely 

Moderate 

H 


on these servers. This is shown by the obstacle Performance vari¬ 
ability of cloud server (027) in the goal model (Fig. 8). 

Step 2.2 Assess obstacles. Technical documents of DDP and an 
early investigation of public cloud platforms revealed the occur¬ 
rence of obstacles Learning curve (033) and Incompatibility of legacy 
and cloud service (048) was Almost Certain with a Major conse¬ 
quence on the satisfaction of the goal Achieve [Reduced cloud adop¬ 
tion cost], indicating an Extreme risk. Note all leaf obstacles were 
assigned a risk value based on the likelihood of their occurrence 
and consequence as shown in Table 8. 

Step 2.3 Resolve goal obstacles. The system architect tried to 
tackle obstacles Learning curve (033) and Incompatibility of legacy 
and cloud service (048) by using the resolution tactics Substitute 
cloud service (T3) and Goal weakening (T36). Substitute cloud service 
(T3) is to resolve an obstacle by selecting/changing a cloud ser¬ 
vice/provider in a way that the new selected cloud service can still 
contribute to quality goals. As DDP had been developed with Mi¬ 
crosoft family technologies and developers had programming ex¬ 
perience of, choosing Microsoft Azure cloud platform was taken 
precedence over other popular cloud platforms such as Amazon 
Web Service and Google App Engine. This choice could also con¬ 
tribute to the goal Achieve [Reduced cloud adoption cost] by decreas- 
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Fig. 9. Obstacles to the goal Achieve [Reduced cloud adoption cost] and applied resolution tactics Substitute cloud service (T3) and Degrade goal (T36). 


ing the likelihood occurrence of incompatibilities between DDP 
and Microsoft Azure cloud platform from initial value Almost Cer¬ 
tain to Possible. 

In some cases that an obstructed goal is found to be very ide¬ 
alistic, its definition can be changed to make its constraints re¬ 
laxing in a way that the obstruction occurrence become tolera¬ 
ble. In this regard, the tactic Degrade goal (T36) was used by for 
the goal Achieve [Reduced cloud adoption cost] by extending the 
project deadline from 90 to 120 days. Fig. 9 shows the produced 
goal model thus far. 

The obstacle resolution is an iterative process in the sense that 
once a tactic is chosen, it may raise new obstacles that should be 
resolved accordingly by reiterating Steps 2.1 to 2.3 and refining the 
goal model. In the current scenario, despite applying the resolu¬ 
tion tactic Substitute cloud service (T3) to reduce the obstacle In¬ 
compatibility of legacy and cloud service (048), the domain informa¬ 
tion about DDP and cloud platform Microsoft Azure documentation 
confirms that the violation from the goal Achieve [Reduced cloud 
adoption cost] is still possible because DDP’s APIs are not com¬ 
patible with their counterparts in the Microsoft Azure cloud plat¬ 
form. The obstacle Incompatibility of legacy and cloud service (048) 
is refined into two obstacles Incompatible APIs (044) (i.e. between 
DDP and Microsoft Azure platform) and Incompatibility of legacy 
data storage and cloud (049). The parent obstacle Incompatibility of 
legacy data storage and cloud (049) is also refined into two leaf do¬ 
main specific obstacles (Fig. 10). The definition of the leaf obstacles 
against the goal Achieve [Reduced adoption cost] is as follows: 


Obstacle Incompatible APIs (044) 

Definition [DDP uses API’s offered by .NET 2.0 and Visual Stu¬ 
dio 2005 which may not be compatible with Microsoft Azure 
platforms]. 

Obstacle Incompatible datatypes (021) 

Definition [Datatypes in DDP are based on SQL Server Database 
.NET 2.0 platform which might not be compatible with Mi¬ 
crosoft Azure database solution]. 

Obstacle Incompatible data operations (050) 


Definition [Data operations in DDP supported by SQL Server 
Database .NET 2.0 platform might not be compatible with 
Microsoft Azure database solution]. 

In addition to abovementioned obstacles, applying tactic Sub¬ 
stitute cloud service (T3) generated new obstacles specific to Mi¬ 
crosoft Azure Platform. That is, the root obstacle Microsoft Azure 
middleware latency (029) was refined into three leaf obstacles, Mi¬ 
crosoft Azure database middleware latency (029_l), Microsoft Azure 
message middleware latency (029_2), and Microsoft Azure transac¬ 
tion middleware latency (029_3). In addition, the obstacle Service 
latency (047) was refined into two obstacles On-premise hardware 
latency (047_l) and Distance from Microsoft Azure servers (028). 
Fig. 11 shows goal model refined after using the resolution tactic 
Substitute cloud service (T3) and based on evidential information 
provided from the repository. For simplicity, the system architect 
has changed the original names of some obstacles identified from 
the repository but obstacle codes left unchanged. For example, in 
Fig. 11, the obstacle Backward incompatibility (042) was changed to 
Switch between regular file system API to Microsoft Azure Storage API 
(042). 

To handle new obstacles generated as a result of applying 
the tactic Substitute cloud service (73), the system architect se¬ 
lected resolution tactics from the category Obstacle prevention 
(Appendix B) as described in the following. For the obstacles In¬ 
compatible data operations (050) and Incompatible datatypes (021), 
the system architect used Develop adaptor (T6) and Adapt data 
(T12), respectively. The former is to implement a wrapper compo¬ 
nent which hides the incompatibilities (e.g. queries and stored pro¬ 
cedures) between the data layer of DDP and Microsoft Azure SQL 
whilst the later tactic is to convert SQL data types used in DDP to 
Microsoft Azure SQL database. To resolve the obstacle Incompatible 
APIs (044), the tactic Develop adaptor (76) was used. For the ob¬ 
stacle High-time for session handling (043), the tactics Make system 
stateless (729) was used. Also, in handling the obstacle Switch be¬ 
tween regular file system API to Microsoft Azure Storage API (042), 
the architect selected the tactic Decouple system components (77) 
from the repository. 
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Legend 

LJ 


l_i 


Contribution 


Migration Type 

Goal 

Obstacle 

Decomposition 


Fig. 11. Refined goals models after identifying obstacles. 


To reduce the probability occurrence of the root obstacle Mi¬ 
crosoft Azure middleware latency (029), the adopted resolution tac¬ 
tics was Refine network topology (T24) which belongs to Obstacle 
reduction group. This tactic was operationalized through select¬ 
ing Microsoft Azure servers close to InformIT s network located in 


North Europe. For the obstacle Browser latency (046) the tactic Up¬ 
date patches (T21) is used regularly. 

Furthermore, in addressing the obstacle Performance variability 
of Microsoft Azure servers (027), the system architect applied De¬ 
grade goal (T36), a tactic from Goal weakening group, to modify the 
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Table 9 

Repository support of obstacles and corresponding resolution tactics to address them. 


Goal 

Obstacle 




Adopted resolution tactics 


Obstacle 

Likelihood 

Consequence 

Risk 


Achieve 

033 

Almost 

Major 

E 

Substitute cloud service (T3). Among three major cloud platforms Amazon Web Services, Google 

[Reduced 


Certain 



App Engine, and Microsoft Azure, the architect choses Microsoft Azure because the legacy 

adoption cost] 





system has been developed using Microsoft family technology and system developers has 
consistent experience with it. This reduces the cost of learning cloud technology and also 
potential effort in addressing incompatibilities between legacy system and the cloud. 


044 

Likely 

Moderate 

H 

Develop adaptors (T6). A wrapper component is developed to resolve API mismatches between 






legacy system and Microsoft Azure. It hides specific Microsoft Azure characteristics that cause 
conflicts with the legacy system. 


021 

Almost 

Moderate 

E 

Adapt data (712). The legacy system data types are converted to Microsoft Azure cloud database 



Certain 



solution. 


050 

Almost 

Moderate 

E 

Develop adaptor (T6). As the Microsoft Azure does not support some kind of stored procedures, an 



Certain 



emulator is implemented and deployed on Microsoft Azure server which performs missing 
functionalities that are not supported by this platform. 

Achieve 

042 

Likely 

Moderate 

H 

Decouple system components (77). Legacy system components are decoupled so that dependency 

[Improved 





among them is minimized and they can work independently and interact in a-synchronised way. 

Portability] 





A mediator component is implemented to manage interaction between the loosely coupled 
components deployed on Microsoft Azure servers. 

Achieve 

029_2 

Likely 

Moderate 

H 

Refine network topology (724). Define the geographical location of virtual machines close to North 

[Improved 

testability] 

029_1 

Likely 

Moderate 

H 

Europe to minimize latency of Azure middleware. 


029_3 

Likely 

Moderate 

H 


Achieve 

027 

Likely 

Major 

E 

Acquire more cloud resources (726). Rent three virtual machines to address slow CPU clock rates. 

[Improved 





Use physical disk shipping to reduce effects of network latency/transfer rates. Use third party 

performance] 

029_2 

Likely 

Moderate 

H 

monitoring tools to independently verify the system performance. 


029_1 

Likely 

Moderate 

H 



029_3 

Likely 

Moderate 

H 



029 

Likely 

Moderate 

H 

Make system stateless (729). Legacy system components should be modified in a way that they do 






not depend on internal state. Rather, such states should be stored in an external storage or 
requested from an external component. 


028 

Likely 

Moderate 

H 

Refine network topology (724). Modify the current deployment and distribution model of legacy 






system components on the basis of transaction delay, proximity, and geographical distribution. 

In this case, system components are deployed in Microsoft Azure servers located in North 

Europe close to Sweden to reduce latency. 


046 

Likely 

Moderate 

H 

Update patches (721). Update cloud service consumer browsers regularly. 


047_1 

Possible 

Insignificant 

L 

Do nothing (741). This obstacle is not perceived critical. 


definition of satisfaction level for the root goal Achieve [Improved 
performance]. The tactic refined this goal to a more liberal one via 
allowing the expected processing time of documents by DDP to be 
varied up to 2 hours in a peak time for documents with size more 
than 40 megabyte. The suggested tactic was hard to get acceptance 
by DDP users; however, the purpose of considering this tactic was 
to probe possible solutions to tackle the obstacle. Hence, the sec¬ 
ond tactic was Acquire more cloud resources (T26) operationalized 
by adding 3 more virtual servers. 

The occurrence likelihood of the obstacle On-premise hardware 
latency (047_1) was found Possible with a consequence as Insignif¬ 
icant (i.e. Possible * Insignificant = Low risk) and thus left unre¬ 
solved using the tactic Do-Nothing. Fig. 12 shows the resultant goal 
model and incorporation of resolution tactics into the system ar¬ 
chitecture. Table 9 summarises all identified obstacles and selected 
resolution tactics. 


6. Related work 

Early stage analysis of cloud computing adoption has been pre¬ 
viously investigated by other authors. Drawing upon some relevant 
studies to compare decision making frameworks e.g. (Babar et al„ 
2004) and following some guidelines for legacy system cloud en¬ 
ablement (Fahmideh et al., 2016)), eight analysis criteria were 
identified: migration type, lifecycle focus, evaluation granularity, 
process support, stakeholder involvement, modelling language, ex¬ 
perience repository, and tool support. In what follows, existing lit¬ 
erature is discussed in view of these eight criteria. This will situ¬ 


ate the proposed framework in the literature and will highlight its 
contributions to the state of art. 

(i) Migration type. As mentioned in Section 4.1, there are few 
options, namely type I, II, III, IV, and V, in enabling legacy systems 
to utilize cloud service. In view of this criterion, (Anstett et al., 
2009) presents some factors such as operating system and plat¬ 
form middleware that a system architect should take into ac¬ 
count when deploying business process engines in IaaS, i.e. mi¬ 
gration type I. For migration type II in which legacy system com¬ 
ponents are substituted with cloud services through SaaS model, 
(Godse and Mulik, 2009a) and (Wu et al., 2011) are two example 
frameworks presenting approaches for selecting the most appropri¬ 
ate SaaS product for organizational needs. For the migration type 
V where the whole legacy system stack is encapsulated in virtual 
machines and then ran in the cloud infrastructure, the framework 
proposed in Khajeh-Hosseini et al. (2012) supports decision mak¬ 
ers in identifying concerns to examine the costs of deploying IT 
systems on the cloud. We did not find any noticeable framework 
in relation to migration types III and IV. 

(ii) Lifecycle focus. Decision making frameworks can be clas¬ 
sified considering migration phases for which a framework is ap¬ 
propriate to use. Fahmideh et al. define three migration phases: 
plan, enable, and maintain (Fahmideh et al., 2016b). Frameworks 
related to the planning phase are concerned with the feasibility 
assessment of adopting cloud services. Some studies such as El- 
Gazzar et al. (2016), Low et al. (2011) and Wu (2011) mainly inves¬ 
tigate important factors such as security, cost, and organizational 
readiness that should be taken into account when adopting cloud 
services. Other approaches proposed in De Assungao et al. (2009), 
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Fig. 12. Resolutions tactics for handling obstacles (design) are incorporated into a new architecture of DDP during the enablement phase of migration process. 


Deelman et al. (2008), Kondo et al. (2009), Walker et al. (2010), 
and Khajeh-Hosseini et al. (2012) focus on analysing the feasibility 
of cloud adoption from a cost saving point of view. This informs if 
a deployment option is cost effective. Other concerns related to re¬ 
architecting legacy systems to cloud such as data security, interop¬ 
erability of legacy components and cloud services, or system per¬ 


formance are typically not covered in that analysis. In the enable¬ 
ment phase, cloud services that meet given computational require¬ 
ments of legacy systems and the most suitable legacy components 
that can benefit from cloud services are first selected. This is fol¬ 
lowed with defining an optimum deployment of the components 
on cloud servers. Multi-criteria based decision making techniques 
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are applied for shortlisting and ranking of candidate cloud services: 
e.g. Analytic Hierarchy Process (AHP) (Garg et al., 2013; Godse and 
Mulik, 2009b), Analytic Network Process (ANP) (Menzel, Schon- 
herr et ah, 2013). There are situations in which post-migration as¬ 
sessment is needed. The decision making frameworks related to 
this phase may suggest which legacy components is either de- 
migrated to the local environment or enhanced with new cloud 
services based on new needs and changes in the operational envi¬ 
ronment (Scandurra et ah, 2016). 

(iii) Evaluation granularity. The unit of analysis in decision 
making frameworks can be at different levels such as organiza¬ 
tional, legacy system, or component. A system architect may pro¬ 
ceed at one of these levels to evaluate suitability and filter out mi¬ 
gration variants that do not meet their requirements. For exam¬ 
ple, some frameworks such as Nikkhouy (2013), Christoforou and 
Andreou (2013), and how et ah (2011) assess whether an organi¬ 
sation is ready to benefit from cloud services. Other frameworks 
Tak et ah (2011), Juan-Verdejo and Baars (2013), Menzel and Ran- 
jan (2012), Khajeh-Hosseini et ah (2012), Fittkau et ah (2012), 
Saripalli and Pingali (2011), and Calheiros et ah (2011) examine 
which legacy systems are adequate for moving to the cloud using 
migration types V. Furthermore, Leymann et ah (2011) suggest an 
approach to identify legacy system components suitable for being 
cloud-enabled based on other criteria such as latency, data transfer, 
and component dependencies. 

(iv) Evaluation approach. This criterion is useful to know the 
level of information required by a framework and which tech¬ 
niques are required for an evaluation exercise. Decision making 
frameworks use a wide range of techniques to satisfy desired 
goals. To name a few, some frameworks are metric based (e.g. 
De Assun^ao et ah, 2009; Deelman et ah, 2008; and Rondo et ah, 
2009), some use goal-based reasoning (e.g. Zardari et ah, 2014 and 
Scandurra et ah, 2016), some use optimisation technique (e.g. 
Leymann et ah, 2011) and other use hybrid techniques (e.g. 
Menzel and Ranjan, 2012; Fittkau et ah, 2012; Saripalli and Pin¬ 
gali, 2011). 

(v) Process support. Decision making frameworks may define a 
precise definition of their steps and sequencing. They may clearly 
describe for each step the input and the output products, their 
guidelines, controls, and any heuristics for an accurate assessment. 
They ultimately help a system architect to accomplish decision 
making goals. Except for some frameworks presented in Table 1, 
the majority of frameworks reviewed in this section provide at 
least a coarse-grained description of their process, though they dif¬ 
fer in the level of details provided. However, it should be said that 
some frameworks related to the planning phase of cloud adoption 
do not have an explicit process support. 

(vi) Stakeholder involvement. As with many decision mak¬ 
ing scenarios in software engineering, cloud computing adoption 
may involve multiple stakeholders such as cloud service providers, 
consumers, brokers, developers, project managers, and end-users 
whose interests attempt to influence risks and benefits. These 
stakeholders may well have their own competing interests and 
attempt to influence the risks and benefits assessment process. 
Their active participation enables proper elicitation of their goals 
and priorities. Resolving conflicts during decision making process 
is essential for the final quality of assessment process. Existing 
frameworks generally recognize the importance of incorporating 
key stakeholders, but they vary in how and to what degree stake¬ 
holders are engaged. 

(vii) Modelling language. Evaluation frameworks can be com¬ 
pared in terms of if and how they employ a notation to repre¬ 
sent elements, semantic interpretation, and outcome of each de¬ 
cision step. Using a modelling language can facilitate communi¬ 
cations and understandability of the decision making process to 
stakeholders. It can also provide scope for automation of parts 


of the process. For example, the framework by Christoforou and 
Andreou (2013) uses Influence Diagrams, a directed acyclic graph 
with nodes, to show decision variables and how they influence 
each other. Nodes representations along with their dependencies 
model decision making questions and provide final decision nodes. 
In another framework, Zardari et ah (2014) goal-oriented modelling 
is used to represent risks encountered and mitigating strategies in 
using cloud services. 

(viii) Experience repository. The notion of reuse is a peren¬ 
nial means for increasing productivity in software engineering 
(Aurum et ah, 2003). Like any other software development ac¬ 
tivity, cloud migration decision making is a knowledge-intensive 
process. It can be a costly exercise if it starts from scratch in 
an ad-hoc manner or in an ad-hoc manner each time. The ef¬ 
fort involved can clearly be reduced if knowledge from activ¬ 
ities in previous cloud computing adoption scenarios is main¬ 
tained and reused. Towards this, CLiCk (Cloud Life Cycle) pro¬ 
vides a repository containing historical information on QoS of dif¬ 
ferent service platforms to improve the accuracy of service se¬ 
lection (Giovanoli, 2012). Reusing and sharing recurring decision 
logs in the course of re-architecting legacy systems to cloud plat¬ 
forms is suggested in Zimmermann et ah (2015). In another work, 
Menzel et ah (2013) provides a reusable catalogue of criteria for 
creating customized evaluation methods to evaluate alternative 
service providers. 

(ix) Tool support. A decision making process can involve time 
consuming tasks such as collecting, documenting, and maintain¬ 
ing relevant domain data. Particularly, at the early stage of tran¬ 
sition to the cloud, consumers may face a higher number of 
risks in utilizing cloud services which should be carefully eval¬ 
uated (Lacity et ah, 2009). Decision-making tools can capture, 
for example, alternative cloud services and their service level 
agreements offering by different providers, costs and risk fac¬ 
tors relevant to decision scope, automate as many as decision 
steps, and come up with evaluation outcomes. The importance of 
tool support is recognized in some frameworks such as Khajeh- 
Hosseini et ah (2012) and Menzel and Ranjan (2012). 

Table 1 provides a summary of the various characterizing ap¬ 
proaches possible of cloud decision frameworks. Our proposed 
framework in the current study distinguishes itself from the exist¬ 
ing one in the view of analysis criterion experience repository. Com¬ 
pared to the existing frameworks reviewed above, our framework 
provides an evidential knowledge repository of reusable cloud- 
specific obstacles and corresponding resolution tactics along with 
a visualization mechanism for systematically analysing risks in mi¬ 
grating legacy systems to cloud platforms. Perhaps, the only no¬ 
table close work to our framework is by Giovanoli (2012) which 
provides a repository containing information on the different ser¬ 
vice providers and their services. However, it does not cover sev¬ 
eral areas of obstacles and resolution tactics (e.g. incompatibilities 
between legacy systems and cloud platforms). None of the existing 
frameworks utilises cloud adoption knowledge during goal reason¬ 
ing to address probable risks and to undertake countermeasures. 
They rather rely on knowledge of system architect which might be 
imprecise and incomplete. Using our framework, system architects 
can get an informed insight of attainability of system quality goals 
via cloud-enablement of legacy systems. They also get a detailed 
goal-obstacle analysis as supported by the evidential knowledge 
repository. 

7. Research contributions 

This study contributes to the cloud computing literature in a 
number of ways. Firstly, it enables system architects to make con¬ 
text driven decision on adopting cloud services rather than merely 
on the basis of their novelty or available anecdotal evidence. The 
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repository component of the framework is, in essence, a knowledge 
sharing platform. It strives to provide a body of documented evi¬ 
dence from the extant literature. This body of knowledge informs 
cloud adoption requirement analysis ultimately enhancing the reli¬ 
ability and any concomitant decision. 

Secondly, an early stage analysis of cloud migration goals is not 
trivial and there is a dearth of research on how to elicit, model, 
and anticipate potential impact of obstacles on them in a system¬ 
atic way. Our proposed framework provides a systematic frame¬ 
work to explore goals, exceptional conditions impeding these goals, 
and to produce a complete set of requirements. The framework has 
been built on top of the empirical knowledge that makes results 
of goal-obstacle analysis more reliable compared to a situation in 
which the analysis is merely based on general knowledge of cloud 
platforms or personal experience of the system architect. The out¬ 
put from the framework is a goal-oriented requirements model 
relating cloud migration quality goals to risky obstacles follow¬ 
ing with operational countermeasures. This model gives the sys¬ 
tem architects a broad view of rationale and costs of specific re¬ 
quirements before delving into the technical integration aspects of 
legacy systems with cloud services. The model can be incorporated 
into the implementation stage to make appropriate trade-offs on 
basis of, for example, cost, security, or performance goals. Not only 
the framework applicability is positioned in the earliest stage of 
migration, but it can also be used during post-migration stage to 
tackle costly mistakes. 

Finally, the framework can be employed to complement exist¬ 
ing decision making frameworks as reviewed in Section 6. It fills 
their gaps in reusing existing empirical knowledge and the strate¬ 
gic goals of the overall migration process. It can be also used as 
a stand-alone framework for goal-obstacle analysis of cloud migra¬ 
tion types to reason about risky obstacles against system quality 
goals that an organization expects. Our framework takes a qualita¬ 
tive goal-obstacle analytical approach as its aim is not to quantita¬ 
tively measure probability occurrence of obstacles or goal achieve¬ 
ment, instead; the framework simply intents in specifying cloud 
migration goals that might be impacted by obstacles. We hope the 
current study provides a motivation of combining the evidence- 
based software engineering and goal-oriented modelling literature 
and stimulate more efforts in the context of cloud computing. 

8. Threats to validity 

Our framework has been validated to account for both inter¬ 
nal and external validity threats. Internal validity threats relate to 
factors that a researcher has not been aware of and may have 
affected the research outcome i.e. the framework artefact itself 
(Wohlin et al„ 2012). External validity threats relate to the extent 
to which the resulting framework can be generalised (Wohlin et al., 
2012 ). 

To ensure the repository’s coverage, we focused on studies per¬ 
taining to legacy systems transition to cloud platforms in the SLR 
depicted in Fig. 2. The SLR identified 112 studies and two item¬ 
ized collections, respectively, presented in Appendix A and B. SLRs 
are generally criticised for being a too mechanical, rigid protocol- 
driven, and formal process for the study selection process and re¬ 
view which limits research’s curiosity and scholarly examining of 
knowledge in a literature review (Fijorland, 2011; Boell and Cecez- 
Kecmanovic, 2015). Another common concern associated with SLRs 
is their indeterminacy and multiplicity of the domain language. 
This latter concern is of particular relevance to the cloud com¬ 
puting field where precise terminologies or nomenclature have not 
yet been grounded. A particular obstacle or resolution tactic may 
be expressed using different terms and vocabularies. For example, 
we found that studies identified in Appendix A do not necessar¬ 
ily use the search strings presented in Table 2 or terms goals, ob¬ 


stacles, resolution tactics, and decision making. To mitigate against 
the incompleteness of the framework repository, e.g. due to miss¬ 
ing some important and reusable empirical findings, our SLR had 
a phase for early understanding and critical reading of the cloud 
migration literature before it is fine-tuned as shown in Fig. 2. 
For example, we did not confine ourselves with exemplar fixed 
search strings presented in Table 2; rather, we sought concepts 
related to goals, obstacles, and resolution tactics and not merely 
for search strings because such concepts were not only expressed 
using search strings and sometimes they were described or para¬ 
phrased. With all due care taken above in conducting the SLR, it is 
not possible to affirm that the repository is error-free. 

The reliability of case studies has been subjected to the qual¬ 
ity and accuracy of the written documents of these migration 
scenarios. The documents provided by project owners may have 
been slightly different from activities that actually had been per¬ 
formed due to reasons such as hindsight bias or error in remem¬ 
bering details. As a consequence, there is a possibility of miss¬ 
ing the identification of some new obstacles and resolution tac¬ 
tics that could be added as new entry to the framework reposi¬ 
tory or change the procedure’s step of the framework. This may 
have weakened internal validity of running case studies. To mit¬ 
igate against this, we conducted follow-up communications with 
key document providers to confirm the validity of the documents 
of projects and to provide any missing information. 

In addition, an often-cited limitation of case studies is their 
specificity to a particular context at a particular point in time 
which circumscribes generalisability of the results to other applica¬ 
tions and contexts. Although the framework was validated through 
two idiosyncratic case studies, its applicability to all possible cases 
can still of course be debated. The repository is however extensible 
with new entries if more case studies are performed. 

Furthermore, we do not claim the framework procedure is com¬ 
plete to provide a great analysis of all scenarios of legacy systems 
transition cloud platforms. There might be some short-cuts to sat¬ 
isfy goals, or some hidden factors that hinder certain goal achieve¬ 
ment but are not detected in the framework procedure. At this 
stage, there is no assertion regarding the generalisability of the 
procedure beyond the cases investigated in this study. But it can 
be extended with new steps if the framework is appraised with 
more case studies in a variety of scenarios. 

9. Conclusion and future work 

Operational large legacy systems that store critical and histori¬ 
cal data accumulated over many years may not have been devel¬ 
oped in a way accounting for concerns related to cloud environ¬ 
ments such as security, elasticity, multi-tenancy, and interoperabil¬ 
ity. This article has been on this premise that moving these critical 
systems to the cloud may involve uncertain risks that should be 
systematically explored and mitigated in early stages where there 
is more flexibility to handle risks instead of experiencing them at 
later stages which might be costly once the legacy system is in 
operation in the cloud. Endeavours towards legacy system cloud 
enablement are sometimes rewarding or challenging along with 
many lessons learned along the way. Reusing these lessons in dif¬ 
ferent cloud migration scenarios is a promising approach in better 
exploration of these risks and reliability of decision outcomes. In 
this regard, our proposed framework harnesses a synergy between 
evidence-based software engineering and goal-oriented modelling ap¬ 
proaches. The framework comprises an evidence-based repository 
of goals, obstacles, and corresponding resolution tactics that are 
utilized to improve the reliability and accuracy of decision out¬ 
comes in migrating legacy systems to cloud platforms. The pro¬ 
posed framework is the first attempt turning the existing body of 
knowledge of moving legacy systems to the cloud into a concise, 
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accessible, and a reusable source. This has not been a feature of 
the past research. 

Some deficiencies regarding the completeness of the repository 
are clear areas for further research. There is an unequal availabil¬ 
ity of empirical studies in the literature in support of the repos¬ 
itory collections. In one hand, as shown in the Appendix B and 
suggested by several studies, the resolution tactic Develop adap¬ 
tor/wrapper (T6) can be used in addressing several obstacles 
namely Incompatible pluggable cloud services (019), Incomplete APIs 
(020), Incompatible data types (021), Operating system incompatibil¬ 
ity (022), Machine-image incompatibility (023), Virtual machine con- 
textualization incompatibility (024), API incompatibility across mul¬ 
tiple cloud (025), and Proprietary APIs (036). On the other hand, 
there is only one resolution tactic to address the obstacle Extra 
testing effort (032) which is Prioritize tests (T30). Hence, further re¬ 
search is required to add more empirical findings to the repository 
as more studies appear in the cloud computing literature. 


Our future work includes adding a probabilistic layer for goal 
specification and obstacle assessment in view of their estimation 
and required degrees of satisfaction grounded on system domain. 
The criticality of obstacle consequences will be computed by prop¬ 
agation probabilities from leaf obstacles towards high-level goals 
through the goal refinement model. To this aim, we will extend 
the procedure steps of the framework by annotating obstacle and 
goal elements with the probability of their occurrence (Cailliau and 
van Lamsweerde, 2013). In addition, the framework repository in 
its current state is stored in textual template and does not pro¬ 
vide a systematic mechanism for regularly updating the repository 
with new empirical data as identified in the literature. In addition, 
the goal-obstacle procedure utilizing the repository is also manual. 
These deficiencies confine the usability of the framework. We plan 
to provide a tool support for using the framework that facilitates 
its usage when working with large scale goal models. 

Appendix A. Studies used to create the knowledge repository 
of the framework 
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Appendix B. Collections in the framework repository 


Catalogue of goals commonly contributed by cloud computing technology 


# Quality goal Explanation (from cloud service consumer perspective) 

Study 


G1 

Availability 

G2 

Scalability 

G3 

Security 

G4 

Performance 

G5 

Customizability 

G6 

Interoperability 

G7 

Portability 

G8 

Testability 

G9 

Consistency 

G10 

Reduced IT cost 


Anywhere/anytime/any device (desktop, laptop, and mobile) access to resources (e.g. CPU, 
storage, virtual machines, and network bandwidth) which are redundant and guarantee more 
availability (24/7/365 and 99.99% availability) compared to run in-house infrastructure. 

On the fly scaling up/ down resources and capability to provide varying resource demanding 
patterns. 

Providing secure services protected from unauthorized access by other tenants. 

An excellent throughout speed and computations on cutting edge infrastructure. 

Customisable and modifiable services upon requirements of consumers. 

Cloud services are integrable and incorporable with systems as required. 

Systems can move from one cloud to another cloud to get better offer (e.g. performance, price, 
and security) with minimum disruption. 

Providing a scalable infrastructure to perform test and evaluation of high-computational tasks. 
Guarantee of data consistency and not resulting in an error state for the system once data are 
processing and changing in the cloud. 

Lower expense for infrastructure procuring, data storages, software updates, maintenance, and 
staff. 


[S2], [S3], [S4], [S5], [S35], 
[S36], and [S37]. 



Probable obstacles against goals in migrating legacy systems to cloud platforms 

Quality goals 


Migration type* 


# Obstacle 


Definition 


<D *5 

O 72 


II III IV V 


Study 


Ol 

Cloud outage 

A cloud provider may suffer from outages for reasons such as going 
out of business, being the subject of regulatory action, or the outage of * 
contacts system. 



V 

V 

V 

V 

V 

[S2], [S44], [S58] 



Cloud service may be unavailable and callable by service consumer 



V 

V 

V 

V 

V 


02 

Service failure 

due to reasons such as network congestion, hardware failure, service * 
middleware failure, or faults on various elements of service platforms. 



[S2], [S9] 






03 

Service transient fault 

Cloud service maybe temporarily unavailable due to network traffic * 
load or restarting by administrators after a failure. 



V 

V 

V 

V 

V 

[S2], [S9] 

04 

Tenant interfere 

Several tenants maybe in run on the same cloud and negatively affect 
the system data security. 

* 


V 

V 

V 

V 

V 

[S59], [S60], [S88] 

05 

Un-customisable 

scalability 

The scalability rules may not be flexible and merely controlled and 
managed by service provider. 

* 

* 

- 

V 

- 

- 

- 

[S10], [SI 1] 



Cloud service may have delay in providing resource requested by 









06 

Scaling latency 

service consumer due to reasons such as a server workload in the 
region, the rate of load acceleration, or quotas imposed by the cloud 
service provider. 

* 


V 

V 

- 

V 

V 

[S12], [S13], [S14] 

07 

Browser vulnerabilities 

Cloud consumer who connects to cloud services by a Web browser 
might be attacked by a malicious tenant. 

* 


V 

V 

V 

V 

V 

[S15], [SI6] 

08 

Code disruption 

System codes are performing in the cloud might be accessed and 
disrupted by other tenants are in operation in the same cloud. 

* 


V 

- 

- 

- 

V 

[S6], [SI7] 

09 

Cloud attack 

A malicious tenant can disrupt cloud service functionalities. 

* 


V 

V 

V 

V 

V 

[S16], [S17], 
[S45], [S58] 

010 

Extra security cost 

There might be an extra cost to address security if system components 
are deployed across different cloud server with complex relationships 
and security configuration which demands for provider-independent 
methods to establish a security and configuration context. Service 
consumer might be responsible for locking ports, patching the 
operating system, running an anti-virus software and enforcement of 
access control policies. 



* sj 

V 

V 

V 

V 

[S6], [S26], [S28] 

Oil 

Lack of control on code 
execution location 

Executing of a system in the cloud might not be fixed to a geographical 
location and rather the system may move from one physical server to 
another one during its lifetime. The decision on the execution location 

* 


V 

- 

- 

- 

V 

[S17], [SI9] 
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of the system is based on factors such as load balancing mechanism of 
cloud, network and server performance and availability, and even 
characteristics of the current consumer. 

012 

Lack of control on data 
location 

Sensitive data may move to the outside the organization network or 
country. There is no assumption where the location of the data is. 

* 



- 

V 

V 

V 

V 

[S12], [S20], [S21] 

013 

Data remanence 

The residual representation of data after finishing system execution on 
the cloud server may cause unwilling disclosure of private data. 

* 



- 

V 

V 

V 

V 

[S22] 

014 

Data interruption 

Tenants or subcontractors of cloud providers may get access to system 
data and affect data confidentiality. 

* 



- 

V 

V 

V 

V 

[S29] 

015 

Session hijacking 

A malicious tenant may use a valid session key to get authorised 
access to use system using cloud service. 

* 



V 

V 

- 

- 

V 

[S29] 

016 

System source codes 
propriety 

Cloud provider, its subcontractors, or tenant may get access to all 
system codes/algorithms which might be confidential. 

* 



V 

V 

- 

- 

V 

[SI 7] 



System owner is dissatisfied with cloud service but it cannot easily and 










017 

Vendor lock-in 

inexpensively transfer its system and data to another platform or in- 
house. 


* 

* 

V 

V 

V 

V 

V 

[S50], [S51], [S52] 

018 

Traversal vulnerability 

A malicious tenant may damage resources that are used by other 
tenants. 

* 



V 

V 

V 

V 

V 

[S59], [S60], 
[S61], [S621 

019 

Incompatible pluggable 
cloud services 

At runtime, system might be plugged to a cloud service which is 
incompatible with the other cloud services. 


* 

* 

V 

- 

- 

- 

V 

[S23] 

020 

Incomplete APIs 

Cloud service provider lacks providing a rich set of APIs. 


* * 

* 

~^r 


- 

V 

V 

[S241 

021 

Incompatible data types 

Data types used in legacy and cloud service are incompatible. 


* 

* 


•V 

- 

V 

V 

[S121, [S381 

022 

Operating system 
incompatibility 

System components are distributed and moved among cloud servers 
with different operating systems which might be incompatible for 
managing, representing, and formatting virtual machines. 


* 

* 

V 

- 

- 

- 

V 

[S25], [S26], [S27] 

023 

Machine-image 

incompatibility 

Virtual machines are moving between different cloud platforms but 
each platform has different underlying implementation for virtual 
machines. 


* 

* 

V 

- 

- 

- 

V 

[S39], [S40] 

Q24 

Virtual machine 

contextualization 

incompatibility 

Virtual machines are moving between different platforms but each 
platform may use different methods for customizing the context of 
virtual machine such as setting the operating system’s username and 
password. 


* 

* 

V 

V 

- 

- 

V 

[S39],[S40] 

025 

API incompatibility 
across multiple cloud 

Cloud service may offer APIs to implement systems or virtual 
machines which might be incompatible with each other services. 


* 

* 

V 

- 

- 

- 

V 

[S25], [S26], 
[S271, [S30], [S401 

026 

Message passing 

Message passing between system and cloud services or among system 
components deployed on cloud servers might be unsecure and accessed 
by malicious tenants. Also, message size might be large affecting 
system performance. 

* * 



V 

V 

V 

V 

V 

[S12], [S45] 

027 

Performance variability 
of cloud service 

Workload variability, virtualization overheads, or resource time¬ 
sharing of cloud server may have negative effect on the system 
performance operating in the cloud. 

* 



V 

V 

- 

- 

V 

[S12], [S31], 
[S32], [S93] 

028 

Geographical distance 

High distance between system components that are distributed and 

* * 



7" 



V 

V 

[S12] 
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t_n 

O 


deployed on cloud servers may cause increased latency when accessing 
or manipulating the data. 

029 

Low middleware 
performance 

A cloud service may have been built on several layers of middleware, 
from the guest operating system of the VM to the data-centre resource 
manager, which each middleware may impact on the system 
efficiency. 

* 

* * 


V 

V 

- 

V 

V 

[S32] 

030 

High cancellation fees 

Cloud service provider may force a consumer to a long term 
commitment and consumers’ early exit may causes forfeit. 



* 

V 

V 

V 

V 

V 

[S33] 

031 

Inflexible pricing model 

Cloud service provider may not offer a billing model based on the 
service usage and limit consumer to flat rates or usage thresholds. 


* 


V 

V 

V 

V 

V 

[S34] 

032 

Extra testing effort 

The test of system which may be deployed on multiple cloud servers 
may needs testing connectivity of local components and those 
deployed on cloud servers along with adding a new dimension of test 
such as elasticity, multi-tenancy, interoperability, and elasticity. 


* * 


V 

V 

V 

V 

V 

[S37], [S41], 
[S42], [S95] 

033 

Learning curve 

Learning a new programming style, concepts, APIs, tools, and 
understanding organisational impact of the cloud technology might be 
time consuming. 



* 

V 

V 

V 

V 

V 

[S43] 

034 

Loose of control over 
resources and updates 

Loss of control over resource management and their update. 


* 


V 

V 

V 

V 

V 

[S45], [S46] 

035 

Bargaining power of 
provider 

Cloud provider may get bargaining power in the future for example by 
raising service fee prices or refusing to invest maintenance backward 
compatible interface. 


* 


V 

V 

V 

V 

V 

[S48], [S49] 

036 

Proprietary APIs 

Proprietary cloud APIs may impede integration of cloud services with 
legacy systems. 


* * * 


V 

V 

V 

V 

V 

[S53], [S54] 

037 

Licensing issue 

Software is charged per instance model but cloud server creates several 
instances in the case of workload occurrence which might be 
contradictory with software licensing. 



* 

V 

V 

- 

V 

V 

[S45], [S55] 

038 

Department downsizing 

The maintenance team of legacy systems may become downsize as 
some of their responsibilities are outsourced to cloud providers. 



* 

V 

V 

V 

V 

V 

[S44], [S56] 

039 

Resistance to change 

Users/staff may resist against moving to the cloud due to change in 
their positions and organisational structure. 



* 

V 

V 

V 

V 

V 

[S36], [S40] 

040 

Non-compliancy 

Users or standard regulations don’t consent to move 
personal/organisational data to the cloud. 



* 

V 

V 

V 

V 

V 

[S57] 

041 

Extra management 
effort 

Maintaining a system deployed in several clouds takes extra effort 
such as keeping relationships with cloud providers, change of 
providers, and monitoring. 



* 

V 

V 

V 

V 

V 

[S44] 

042 

Backward 

incompatibility 

System might not be easily switched between on-premise and cloud 
environments. 


* 


V 

V 

V 

V 

V 

[S77] 

043 

State-based dependency 

System may heavily depend on contextual data, storing on server or 
client, such as configuration changes to operate and remain consistent 
from one session to another one. 

* 

* 


V 

V 

- 

- 

V 

[S71], [S91] 

044 

Incompatible APIs 

Legacy system APIs and cloud’s APIs are incompatible. 


* * 

* 


~T~ 




[S121, T431 
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045 

Network latency 

Connection speed between on premise and cloud is low due to latency 
in on-premise network or latency of internal cloud network. 

* * 


V 

V 

V 

V 

V 

[S12] 

046 

Browser latency 

The browser in the on-premise environment is working slowly. 

* * 


a/ 

a/ 

V 

a/ 

A I 

[S12] 

047 

Service latency 

Latency in performing cloud service due to obstacles 07, 028, 046, 
and 045. 

* * 


V 

a/ 

a/ 

V 

V 

[SI 2] 

048 

Incompatibility of 
legacy system and cloud 

Incompatibility between legacy system and cloud services due to 
obstacles 021, 022, 023, Q24, and 025. 


* * * 

V 

V 

V 

V 

V 

[S12], [S43] 


service 










049 

Incompatibility of 
legacy system data 
storage and cloud 

Incompatibility of between legacy data storage and cloud database 
solution due to 021 and 050. 


* * * 

- 

- 

- 

V 

- 

[S12], [S43] 

050 

Incompatible data 
operations 

Operations such as stored procedure, views, and functions providing 
by cloud data store might not be compatible (either syntactically or 
semantically) with those defined in legacy system. 


* * * 

- 

- 

- 

V 

- 

[S12], [S43] 

051 

Tight dependencies 

Tight dependencies among legacy system components or dependency 
to underlying technologies, operating systems, programming language, 
or other legacy systems may obstruct individual scalability and 
portability of components across multiple clouds and on premise. 

* 

* * 

V 

V 

V 

V 

V 

[S67], [S98], 
[S108] 

052 

Inconsistency of system 
components 

Cloud data storage services may offer weaker consistency properties in 
the sense that it will be taken long time to have consistent data across 
all servers. 


* 

- 

- 

V 

a/ 

V 

[S8], [SI8] 

053 

Identity theft 

An attacker may get a valid user’s identity and access resources of 
legacy systems. 

* 


V 

V 

V 

V 

V 

[S104] 

054 

Variable price of cloud 
resources 

The price of using cloud resources may vary depending on cloud 
workload across the time, particularly in a pick period. Such price 
variation may not be suitable for legacy systems with heavy processing 
tasks. 


* 

V 

V 

- 

- 

V 

[SI 12] 

055 

High cost of support 
(Specific to AWS) 

AWS is a general provider which expects its services to be used and 
managed by its uses independently. If a problem occurs, AWS has an 
expensive technical support. 


* 

V 

- 

- 

- 

- 

[S102] 

056 

Unreliable IT support 
(Specific to AWS) 

The quality of IT support by AWS might be a risk. 


* 

V 

- 

V 

- 

V 

[SI 00] 

057 

Varying support fee 
(Specific to AWS) 

AWS support fees vary on a sliding scale tied to monthly in a way that 
support costs may grow quickly if system performs heavy tasks. 


* 

V 

- 

- 

- 

- 

[S101] 

058 

Vulnerable security 
(Specific to AWS) 

Amazon simple storage service (S3) may be accessible via SSL (secure 
sockets layer) encrypted end points, implying that it is the user’s 
responsibility to encrypt data before storing into S3. 

* 


- 

- 

V 

- 

- 

[S103] 

059 

Injection attack 
(Specific to AWS) 

An attacker may hijack user accounts by creating, modifying, and 
deleting virtual machine images, and changing administrative 
passwords to control interfaces used to manage cloud computing 
resources (e.g. S3 or EC2). 

* 


V 

- 

V 

- 

- 

[S104] 

060 

Inflexible cost model 

Azure computes the cost of recourses that were used per minute with 


* 

a/ 

A 1 

A 1 

A I 

A 1 

[S99] 
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(Specific to Azure) 

rounding up service usage to the nearest minute. In other words, if a 
user allocated a resource for one hour and a half, then payment is 
computed for the exact period of time whilst a provider like Amazon 
round up service consumption to nearest hour. 






061 

Inflexible configuration 
(Specific to Azure) 

The provider may not provide high flexible hardware configurability 
for each virtual machine instance compared to Amazon offering high 
flexibility in virtual machine configuration. 

* 

V 

- 

- 

[SI 04] 

062 

Operating system 
incompatibility 
(Specific to Azure) 

Microsoft Azure mainly supports Windows-based servers. Porting 
legacy systems from other platforms (e.g. Linux) to Azure might 
require modifying the source code to be compatible with Windows 

APIs and them able to execute on Azure. 

* 

V 



[SI04], [SI06] 

063 

Limited geographical 
zone (Specific to 
Google) 

Google may not provide an extensive coverage of data centres to 
deploy legacy systems. * 


V 



[SI 07] 

064 

Inflexible cost model 
(Specific to Rackspace) 

Rackspace may offer limited pricing options and month-to-month 
subscriptions. 

* 

V 

- 

- 

[SI 02] 

065 

Heterogeneous 

production 

environments 

The complexity and differences between production environments (e.g. 
cloud platform, third-party clouds, and legacy systems) related to 
deployments and configurations can hinder the efficiency of test. 

* 

V 

V V V 

V 

[SI08], [S109] 

066 

Costly virtual machine 

Virtual machine and its underlying infrastructure might be costly in 
terms of need for large disk storage, isolated binary and library files, 
memory management, and full gust operating system image. 

* 

V 

V - - 

V 

[SI 10] 

067 

Incompatible execution 
environments of system 

A legacy system which is encapsulated in a virtual machine may not be 
interoperable and portable across multiple cloud platforms. 

* 

V 

V - - 

V 

[SI 10] 

* 

For the migration types see 

: the migration criteria in Section 6. 








Catalogue of resolution tactics for handling obstacle 





# 

Resolution tactic 

Definition 

Relation to obstacle 


Source 


Category 

T1 

Substitute goal 

Identify an alternative goal which is still contributable by the chosen migration type 
or cloud services in a way that the obstructed goal and obstacle will not occur. 

Applicable to resolve all 
obstacles 

KAOS 

methodology 

Goal/Service/Migration 
type Substitution 

T2 

Substitute cloud 
migration type 

Choose an alternative cloud adoption type which satisfies the obstructed goal is 
adopted in a way that the obstacle will no longer occur. The tactics has root in the 
fact that different cloud adoption types, besides their specific contributions to quality 
goals, might have common contributions towards migration goals. 

Applicable to resolve all 
obstacles 

Inspired from 
KAOS 
methodology 

Goal/S ervice/Mi grati on 
type Substitution, Obstacle 
reduction 

T3 

Substitute cloud 
service 

Resolve the obstacle by selecting/changing the cloud service/provider in a way that 
new the cloud service can contribute to quality goals. Define a set of suitability 
criteria that characterise desirable features of cloud providers. The criteria include 
provider profile (e.g. pricing model, constraints, offered QoS, electricity costs, power, 
and cooling costs), organisation migration characteristics (migration goals, available 
budget), and system requirements. Based on the criteria, identify and select suitable 
cloud providers. 

Applicable to resolve all 
obstacles 

Inspired from 
KAOS 

methodology and 
[S65], [S79] 

Goal/Service/Migration 
type Substitution, Obstacle 
reduction 
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T4 

Analyse migration 
feasibility 

Perform a feasibility analysis to evaluate the benefits and the consequences of 
moving legacies to the cloud and its impact on organisation structure, staffs roles, 
and legacies. 

038, 039 

[S73], [S74] 

Obstacle prevention 

T5 

Refactor legacy 
source code 

Adapt the source code for being compatible and able to interact with the selected 
cloud platform programming language and APIs. 

019,020, 021,022, 
023, Q24, 025 

[S65], [S66], [S67] 

Obstacle prevention 

T6 

Develop 

adaptor/wrapper 

Add adaptors for resolving mismatches, occurring at runtime system execution, 
between legacy system components and cloud services. 

019, 020, 021, 022, 
023, Q24, 025, 036 

[S75], [S76] 

Obstacle prevention 

T7 

Decouple system 
components 

Decouple the legacy system components from each other. Use mediator and 
synchronisation mechanisms to manage interaction between the loosely coupled 
components in the cloud environment. 

051 

[S12], [S77], [S78] 

Obstacle prevention 

T8 

Encrypt/decrypt 
message passing 

Add support for the runtime encryption/decryption of message transition between 
components in the on premise network and cloud environment. 

026 

[S12], [S75], [S79] 

Obstacle prevention 

T9 

Obfuscate code 

Protect unauthorised access to code blocks of components by other tenants that are 
running on the same cloud provider. Use encryption mechanisms in the sense that no 
other tenants will be able to access, read, or alter the code blocks with the 
components when running in the cloud. 

08,016 

[S6] 

Obstacle prevention 

T10 

Isolate tenant 

Enable multi-tenancy in the system. Based on multi-tenancy requirement (i) define 
tenant-based identification and hierarchical access control for tenants and (ii) separate 
tenant data using authorization and authentication mechanisms. 

04 

[S80], [S81], [S96], 
[S97] 

Obstacle prevention 

Til 

Tune message 
granularity 

Define suitable granularity for messages, which are passing between components 
hosted on local network and the cloud, based on the degree of functionality that is 
offered to the service consumer and consumer's infrastructure capability to process 
the messages. A proper message granularity can be identified or predicted based on 
pieces of data actually used by system or using heuristic functions to understand the 
number of interaction between system components over the cloud network. 

026 

[S12], [S82] 

Obstacle prevention 

T12 

Adapt data 

Convert legacy data types to the data type of target cloud database solution. Also, add 
an extension component to the legacy which includes a set of commands to be 
performed by the legacy or cloud. The emulator supports missed database 
functionalities of cloud database solution provider. 

050, 021 

[S12], [S38], [S71], 
[S83], [S84] 

Obstacle prevention 

T13 

Involve staff with 
cloud adoption 
process 

Involve staff and stakeholders actively in the cloud adoption process and give them 
insight of benefits of the cloud and organisational change. 

038, 039 

[S46] 

Obstacle reduction 

T14 

Define an 
authorization 

Add a component determining if a tenant has privilege to perform a given action over 
the database. 

04 

[S69] 

Obstacle prevention 

T15 

Encrypt data 

Use data encryption mechanisms prior outsourcing or hosting system data to the 
cloud. 

014,013,04 

[S12], [S79], [S85] 

Obstacle prevention 

T16 

Filter unauthorised 
requests 

Add support to filter unauthorized data access received from users at the edge of 
premise or cloud network as early as possible to avoid unauthorized network traffic. 

014, 04 

[S58] 

Obstacle prevention 

T17 

Adjust security 
policies 

Add support for runtime security assessment of received queries for run on data. 

014, 04 

[S58] 

Obstacle prevention 

T18 

Replicate system 
components 

Partition, replicate, and distribute system components and data (replicas) on multiple 
cloud servers. 

03, 06, 

027, 045, 028 

[S58], [S78], [S86] 

Obstacle reduction 
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T19 

Backup periodically 

Implement a procedure to periodically perform data backup. 

04,014,015,017 

rS71US721 

Obstacle prevention 

T20 

Detect and filter 
intrusions 

Filter unauthorised packets and malformed data traversed between system 
components in local network and the cloud environments. 

04, 08, 09 

[S58], [S70] 

Obstacle prevention 

T21 

Update patches 

Perform regular patch update across system components in the cloud. 

07, 08, 09, 046 

[S741, [S871 

Obstacle reduction 

T22 

Isolate tenant 

Protect tenants' data from to be accessed by other tenants. Each tenant should be 
authorised and able to access to its own data. 

T7 

[S88], [S89], [S90] 

Obstacle prevention 

T23 

Define retry 
policies 

Define retry policies and implement them in the system for the operation to succeed. 

03 

[S66], [S75] 

Goal restoration 

T24 

Refine network 
topology 

Define a proper network topology with a consideration of proximity of servers and 
system components, proper provider equipment, the location of the data centres, 
router hops, and infrastructure bandwidth. 

027, 028, 047, 045 

[S65], [S66], [S74], 
[S77], [S78] 

Obstacle reduction 

T25 

Examine cloud 
service behaviour 

Use benchmarking tools to investigate performance of the cloud under investigation 
before decision making. 

027,011,012,017 

[S32], [S65] 

Obstacle prevention 

T26 

Acquire more cloud 

Rent more VMs or higher spec ones to deal with slow CPU clock rates, use physical 

027 

[S2], [S92] 

Obstacle reduction 

resources 

disk shipping to reduce effects of network latency/transfer rates. 


T27 

Use multiple cloud 
servers 

Deploy and replicate system components in several clouds. 

027 

[S45] 

Obstacle reduction 

T28 

Add intermediation 

Implement an intermediate layer (mediator components) between legacy system and 
cloud services that decouple legacy systems from cloud specific APIs. This helps to 
create intermediate APIs and get indirect service from the cloud. 

06, 029, 047 

[S63], [S64] 

Obstacle prevention 

T29 

Make system 
stateless 

Provide support in the system to the handle safety and traceability of tenant’s session 
when various system instances are hosted in the cloud. 

043 

[S78], [S91] 

Obstacle prevention 

T30 

Prioritize tests 

Perform test cases on the basis of their importance and criticality. 

032 

[S95] 

Obstacle prevention 



There alternative sub-tactics: (i) negotiate with system owner to make a suitable 




T31 

Resolve licensing 
issue 

licensing model which satisfies all parties, (ii) extend legacy system with a new 
component (e.g. VPN tunnel) in a way that cloud services can be indirectly offered to 
them, and (iii) enable a license tracking mechanism through monitoring connections 
between the software system and cloud resources. 

037 

[S72], [S74] 

Obstacle prevention 

T32 

Define weak 
inconsistency 

Implement an eventual consistency or similar weak consistency model for data. 

052 

[S8] 

Obstacle reduction 

T33 

Check compliance 

Check if cloud adoption is compliance with the auditors and cloud providers. 

040 

[S45], [S57] 

Obstacle prevention 

T34 

Clarify roles 

Clarify roles and responsibilities relevant to cloud adoption. 

038, 039 

rS401, [S451 

Obstacle reduction 

T35 

Aware top-level 
management 

Make management aware of the extra effort that might be required for cloud adoption 
in the organisation. 

031,033,035,038, 
039, 041 

[S94] 

Obstacle reduction 

T36 

Degrade goal 

Resolve an obstacle by degrading goal definition and refining its assumption for 
required levels of satisfaction so that the refined goal makes have more freedom for 
violation. 

Applicable to resolve all 
obstacles 

KAOS 

methodology 

Goal weakening 

T37 

Restore goal 

Add a new goal for restoring the satisfaction of the obstructed goal when violated. 

Applicable to resolve all 
obstacles 

KAOS 

methodology 

Goal restoration 

T38 

Mitigate goal 

Add a new goal for mitigating the consequences of an obstacle if it occurs. 

Applicable to resolve all 
obstacles 

KAOS 

methodology 

Goal mitigation 

T39 

Fix inconsistencies 

Perform manual or semi-automate steps to resolve inconsistencies which have 

052 

[S81 

Goal mitigation 
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